What does it mean to program to an interface

Question

I have seen this mentioned a few times and I am not clear on what it means  When and why would you do this    I know what interfaces do  but the fact I am not clear on this makes me think I am missing out on using them correctly    Is it just so if you were to do   IInterface classRef   new ObjectWhatever     You could use any class that implements IInterface  When would you need to do that  The only thing I can think of is if you have a method and you are unsure of what object will be passed except for it implementing IInterface  I cannot think how often you would need to do that    Also  how could you write a method that takes in an object that implements an interface  Is that possible

User · Answer

Programming to an interface is saying   I need this functionality and I don t care where it comes from    Consider  in Java   the List interface versus the ArrayList and LinkedList concrete classes  If all I care about is that I have a data structure containing multiple data items that I should access via iteration  I d pick a List  and that s 99  of the time   If I know that I need constant-time insert delete from either end of the list  I might pick the LinkedList concrete implementation  or more likely  use the Queue interface   If I know I need random access by index  I d pick the ArrayList concrete class

User · Answer

Programming to an interface is saying   I need this functionality and I don t care where it comes from    Consider  in Java   the List interface versus the ArrayList and LinkedList concrete classes  If all I care about is that I have a data structure containing multiple data items that I should access via iteration  I d pick a List  and that s 99  of the time   If I know that I need constant-time insert delete from either end of the list  I might pick the LinkedList concrete implementation  or more likely  use the Queue interface   If I know I need random access by index  I d pick the ArrayList concrete class

User · Answer

Program to an interface allows to change implementation of contract defined by interface seamlessly  It allows loose coupling between contract and specific implementations   IInterface classRef   new ObjectWhatever   You could use any class that implements IInterface  When would you need to do that   Have a look at this SE question for good example  Why should the interface for a Java class be preferred   does using an Interface hit performance  if so how much   Yes  It will have slight performance overhead in sub-seconds  But if your application has requirement to change the implementation of interface dynamically  don t worry about performance impact   how can you avoid it without having to maintain two bits of code   Don t try to avoid multiple implementations of interface if your application need them  In absence of tight coupling of interface with one specific implementation   you may have to deploy the patch to change one implementation to other implementation  One good use case  Implementation of Strategy pattern  Real World Example of the Strategy Pattern

User · Answer

The specific example I used to give to students is that they should write  List myList   new ArrayList       programming to the List interface   instead of  ArrayList myList   new ArrayList       this is bad   These look exactly the same in a short program  but if you go on to use myList 100 times in your program you can start to see a difference   The first declaration ensures that you only call methods on myList that are defined by the List interface  so no ArrayList specific methods    If you ve programmed to the interface this way  later on you can decide that you really need  List myList   new TreeList      and you only have to change your code in that one spot   You already know that the rest of your code doesn t do anything that will be broken by changing the implementation because you programmed to the interface   The benefits are even more obvious  I think  when you re talking about method parameters and return values   Take this for example   public ArrayList doSomething HashMap map     That method declaration ties you to two concrete implementations  ArrayList and HashMap   As soon as that method is called from other code  any changes to those types probably mean you re going to have to change the calling code as well  It would be better to program to the interfaces   public List doSomething Map map     Now it doesn t matter what kind of List you return  or what kind of Map is passed in as a parameter  Changes that you make inside the doSomething method won t force you to change the calling code

User · Answer

You should look into Inversion of Control    Martin Fowler  Inversion of Control Containers and the Dependency Injection pattern Wikipedia  Inversion of Control   In such a scenario  you wouldn t write this   IInterface classRef   new ObjectWhatever      You would write something like this   IInterface classRef   container Resolve lt IInterface gt       This would go into a rule-based setup in the container object  and construct the actual object for you  which could be ObjectWhatever  The important thing is that you could replace this rule with something that used another type of object altogether  and your code would still work   If we leave IoC off the table  you can write code that knows that it can talk to an object that does something specific  but not which type of object or how it does it   This would come in handy when passing parameters   As for your parenthesized question  Also  how could you write a method that takes in an object that implements an Interface  Is that possible    in C  you would simply use the interface type for the parameter type  like this   public void DoSomethingToAnObject IInterface whatever            This plugs right into the  talk to an object that does something specific   The method defined above knows what to expect from the object  that it implements everything in IInterface  but it doesn t care which type of object it is  only that it adheres to the contract  which is what an interface is   For instance  you re probably familiar with calculators and have probably used quite a few in your days  but most of the time they re all different  You  on the other hand  knows how a standard calculator should work  so you re able to use them all  even if you can t use the specific features that each calculator has that none of the other has   This is the beauty of interfaces  You can write a piece of code  that knows that it will get objects passed to it that it can expect certain behavior from  It doesn t care one hoot what kind of object it is  only that it supports the behavior needed   Let me give you a concrete example   We have a custom-built translation system for windows forms  This system loops through controls on a form and translate text in each  The system knows how to handle basic controls  like the-type-of-control-that-has-a-Text-property  and similar basic stuff  but for anything basic  it falls short   Now  since controls inherit from pre-defined classes that we have no control over  we could do one of three things    Build support for our translation system to detect specifically which type of control it is working with  and translate the correct bits  maintenance nightmare  Build support into base classes  impossible  since all the controls inherit from different pre-defined classes  Add interface support   So we did nr  3  All our controls implement ILocalizable  which is an interface that gives us one method  the ability to translate  itself  into a container of translation text rules  As such  the form doesn t need to know which kind of control it has found  only that it implements the specific interface  and knows that there is a method where it can call to localize the control

User · Answer

Programming to an interface has absolutely nothing to do with abstract interfaces like we see in Java or  NET  It isn t even an OOP concept   What it means is don t go messing around with the internals of an object or data structure  Use the Abstract Program Interface  or API  to interact with your data  In Java or C  that means using public properties and methods instead of raw field access  For C that means using functions instead of raw pointers   EDIT  And with databases it means using views and stored procedures instead of direct table access

User · Answer

It is also good for Unit Testing  you can inject your own classes  that meet the requirements of the interface  into a class that depends on it

User · Answer

To add to the existing posts  sometimes coding to interfaces helps on large projects when developers work on separate components simultaneously  All you need is to define interfaces upfront and write code to them while other developers write code to the interface you are implementing

User · Answer

A lot of explanation out there  but to make it even more simpler  Take for instance a List  One can implement a list with as    An internal array A linked list Other implementations   By building to an interface  say a List  You only code as to definition of List or what List means in reality   You could use any type of implementation internally say an array implementation  But suppose you wish to change the implementation for some reason say a bug or performance  Then you just have to change the declaration List lt String gt  ls   new ArrayList lt String gt    to List lt String gt  ls   new LinkedList lt String gt      Nowhere else in code  will you have to change anything else  Because everything else was built on the definition of List

User · Answer

It can be advantageous to program to interfaces  even when we are not depending on abstractions   Programming to interfaces forces us to use a contextually appropriate subset of an object  That helps because it     prevents us from doing contextually inappropriate things  and  lets us safely change the implementation in the future    For example  consider a Person class that implements the Friend and the Employee interface   class Person implements AbstractEmployee  AbstractFriend       In the context of the person s birthday  we program to the Friend interface  to prevent treating the person like an Employee   function party         const friend  Friend   new Person  Kathryn        friend HaveFun        In the context of the person s work  we program to the Employee interface  to prevent blurring workplace boundaries   function workplace         const employee  Employee   new Person  Kathryn        employee DoWork        Great  We have behaved appropriately in different contexts  and our software is working well   Far into the future  if our business changes to work with dogs  we can change the software fairly easily  First  we create a Dog class that implements both Friend and Employee  Then  we safely change new Person   to new Dog    Even if both functions have thousands of lines of code  that simple edit will work because we know the following are true    Function party uses only the Friend subset of Person  Function workplace uses only the Employee subset of Person  Class Dog implements both the Friend and Employee interfaces    On the other hand  if either party or workplace were to have programmed against Person  there would be a risk of both having Person-specific code  Changing from Person to Dog would require us to comb through the code to extirpate any Person-specific code that Dog does not support   The moral  programming to interfaces helps our code to behave appropriately and to be ready for change  It also prepares our code to depend on abstractions  which brings even more advantages

User · Answer

Programming to an interface is saying   I need this functionality and I don t care where it comes from    Consider  in Java   the List interface versus the ArrayList and LinkedList concrete classes  If all I care about is that I have a data structure containing multiple data items that I should access via iteration  I d pick a List  and that s 99  of the time   If I know that I need constant-time insert delete from either end of the list  I might pick the LinkedList concrete implementation  or more likely  use the Queue interface   If I know I need random access by index  I d pick the ArrayList concrete class

User · Answer

I strongly believe hard questions should be explained with easy real-world answers  And in the realm of software design  it s very important   Look at any door in your house  school  church    any building    Imagine some doors got the perils right-bottom  so you have to bow to interact with the door  which is open or close it     Or others got just in the top-left  So  some dwarfs  people with disabilities  or Kevin Hart will not find very amusing and usable such doors     So design is the keyword  create programs to others humans can develop use it   What Interfaces does is to make things easy for other junior senior developers across colossus projects 1   so everybody knows what are they doing with little help from others so you can work as smooth as possible  in Theory       1   How  By exposing the shape of value  So  you don t need documentation  cause the code itself is self-explanatory  Awesome      This answer was not meant to be for language-specific instead of concept-driven  After all  humans are creating tools by writing code

User · Answer

If you program in Java  JDBC is a good example   JDBC defines a set of interfaces but says nothing about the implementation   Your applications can be written against this set of interfaces   In theory  you pick some JDBC driver and your application would just work   If you discover there s a faster or  better  or cheaper JDBC driver or for whatever reason  you can again in theory re-configure your property file  and without having to make any change in your application  your application would still work

User · Answer

Let s start out with some definitions first   Interface n  The set of all signatures defined by an object s operations is called the interface to the object  Type n  A particular interface  A simple example of an interface as defined above would be all the PDO object methods such as query    commit    close   etc   as a whole  not separately  These methods  i e  its interface define the complete set of messages  requests that can be sent to the object   A type as defined above is a particular interface  I will use the made-up shape interface to demonstrate  draw    getArea    getPerimeter   etc    If an object is of the Database type we mean that it accepts messages requests of the database interface  query    commit   etc   Objects can be of many types  You can have a database object be of the shape type as long as it implements its interface  in which case this would be sub-typing   Many objects can be of many different interfaces types and implement that interface differently  This allows us to substitute objects  letting us choose which one to use  Also known as polymorphism   The client will only be aware of the interface and not the implementation    So in essence programming to an interface would involve making some type of abstract class such as Shape with the interface only specified i e  draw    getCoordinates    getArea   etc   And then have different concrete classes implement those interfaces such as a Circle class  Square class  Triangle class  Hence program to an interface not an implementation

User · Answer

program to an interface is a term from the GOF book  i would not directly say it has to do with java interface but rather real interfaces   to achieve clean layer separation  you need to create some separation between systems for example   Let s say you had a concrete database you want to use  you would never  program to the database     instead you would  program to the storage interface   Likewise you would never  program to a Web Service  but rather you would program to a  client interface    this is so you can easily swap things out    i find these rules help me    1  we use a java interface when we have multiple types of an object  if i just have single object  i dont see the point  if there are at least two concrete implementations of some idea  then i  would use a java  interface    2  if as i stated above  you want to bring decoupling from an external system  storage system  to your own system  local DB  then also  use a interface    notice how there are two ways to consider when to use them  hope this helps

User · Answer

A lot of explanation out there  but to make it even more simpler  Take for instance a List  One can implement a list with as    An internal array A linked list Other implementations   By building to an interface  say a List  You only code as to definition of List or what List means in reality   You could use any type of implementation internally say an array implementation  But suppose you wish to change the implementation for some reason say a bug or performance  Then you just have to change the declaration List lt String gt  ls   new ArrayList lt String gt    to List lt String gt  ls   new LinkedList lt String gt      Nowhere else in code  will you have to change anything else  Because everything else was built on the definition of List

User · Answer

If I m writing a new class Swimmer to add the functionality swim   and need to use an object of class say Dog  and this Dog class implements interface Animal which declares swim     At the top of the hierarchy  Animal   it s very abstract while at the bottom  Dog  it s very concrete  The way I think about  programming to interfaces  is that  as I write Swimmer class  I want to write my code against the interface that s as far up that hierarchy which in this case is an Animal object  An interface is free from implementation details and thus makes your code loosely-coupled   The implementation details can be changed with time  however  it would not affect the remaining code since all you are interacting with is with the interface and not the implementation  You don t care what the implementation is like    all you know is that there will be a class that would implement the interface

User · Answer

The specific example I used to give to students is that they should write  List myList   new ArrayList       programming to the List interface   instead of  ArrayList myList   new ArrayList       this is bad   These look exactly the same in a short program  but if you go on to use myList 100 times in your program you can start to see a difference   The first declaration ensures that you only call methods on myList that are defined by the List interface  so no ArrayList specific methods    If you ve programmed to the interface this way  later on you can decide that you really need  List myList   new TreeList      and you only have to change your code in that one spot   You already know that the rest of your code doesn t do anything that will be broken by changing the implementation because you programmed to the interface   The benefits are even more obvious  I think  when you re talking about method parameters and return values   Take this for example   public ArrayList doSomething HashMap map     That method declaration ties you to two concrete implementations  ArrayList and HashMap   As soon as that method is called from other code  any changes to those types probably mean you re going to have to change the calling code as well  It would be better to program to the interfaces   public List doSomething Map map     Now it doesn t matter what kind of List you return  or what kind of Map is passed in as a parameter  Changes that you make inside the doSomething method won t force you to change the calling code

User · Answer

There are some wonderful answers on here to this questions that get into all sorts of great detail about interfaces and loosely coupling code  inversion of control and so on   There are some fairly heady discussions  so I d like to take the opportunity to break things down a bit for understanding why an interface is useful   When I first started getting exposed to interfaces  I too was confused about their relevance   I didn t understand why you needed them   If we re using a language like Java or C   we already have inheritance and I viewed interfaces as a weaker form of inheritance and thought   why bother    In a sense I was right  you can think of interfaces as sort of a weak form of inheritance  but beyond that I finally understood their use as a language construct by thinking of them as a means of classifying common traits or behaviors that were exhibited by potentially many non-related classes of objects   For example -- say you have a SIM game and have the following classes   class HouseFly inherits Insect       void FlyAroundYourHead         void LandOnThings        class Telemarketer inherits Person       void CallDuringDinner         void ContinueTalkingWhenYouSayNo         Clearly  these two objects have nothing in common in terms of direct inheritance   But  you could say they are both annoying     Let s say our game needs to have some sort of random thing that annoys the game player when they eat dinner   This could be a HouseFly or a Telemarketer or both -- but how do you allow for both with a single function   And how do you ask each different type of object to  do their annoying thing  in the same way   The key to realize is that both a Telemarketer and HouseFly share a common loosely interpreted behavior even though they are nothing alike in terms of modeling them   So  let s make an interface that both can implement   interface IPest       void BeAnnoying       class HouseFly inherits Insect implements IPest       void FlyAroundYourHead         void LandOnThings          void BeAnnoying             FlyAroundYourHead            LandOnThings             class Telemarketer inherits Person implements IPest       void CallDuringDinner         void ContinueTalkingWhenYouSayNo          void BeAnnoying             CallDuringDinner            ContinueTalkingWhenYouSayNo              We now have two classes that can each be annoying in their own way   And they do not need to derive from the same base class and share common inherent characteristics -- they simply need to satisfy the contract of IPest -- that contract is simple   You just have to BeAnnoying   In this regard  we can model the following   class DiningRoom        DiningRoom Person   diningPeople  IPest   pests               void ServeDinner             when diningPeople are eating           foreach pest in pests         pest BeAnnoying              Here we have a dining room that accepts a number of diners and a number of pests -- note the use of the interface   This means that in our little world  a member of the pests array could actually be a Telemarketer object or a HouseFly object   The ServeDinner method is called when dinner is served and our people in the dining room are supposed to eat   In our little game  that s when our pests do their work -- each pest is instructed to be annoying by way of the IPest interface   In this way  we can easily have both Telemarketers and HouseFlys be annoying in each of their own ways -- we care only that we have something in the DiningRoom object that is a pest  we don t really care what it is and they could have nothing in common with other     This very contrived pseudo-code example  that dragged on a lot longer than I anticipated  is simply meant to illustrate the kind of thing that finally turned the light on for me in terms of when we might use an interface   I apologize in advance for the silliness of the example  but hope that it helps in your understanding   And  to be sure  the other posted answers you ve received here really cover the gamut of the use of interfaces today in design patterns and development methodologies

User · Answer

Here is a simple example to illustrate when you program a flight booking system     This interface is very flexible and abstract     addPassenger Plane seat  Ticket ticket       Boeing is implementation of Plane     addPassenger Boeing747 seat  EconomyTicket ticket        addPassenger Cessna  BusinessClass ticket         addPassenger J15  E87687

User · Answer

You should look into Inversion of Control    Martin Fowler  Inversion of Control Containers and the Dependency Injection pattern Wikipedia  Inversion of Control   In such a scenario  you wouldn t write this   IInterface classRef   new ObjectWhatever      You would write something like this   IInterface classRef   container Resolve lt IInterface gt       This would go into a rule-based setup in the container object  and construct the actual object for you  which could be ObjectWhatever  The important thing is that you could replace this rule with something that used another type of object altogether  and your code would still work   If we leave IoC off the table  you can write code that knows that it can talk to an object that does something specific  but not which type of object or how it does it   This would come in handy when passing parameters   As for your parenthesized question  Also  how could you write a method that takes in an object that implements an Interface  Is that possible    in C  you would simply use the interface type for the parameter type  like this   public void DoSomethingToAnObject IInterface whatever            This plugs right into the  talk to an object that does something specific   The method defined above knows what to expect from the object  that it implements everything in IInterface  but it doesn t care which type of object it is  only that it adheres to the contract  which is what an interface is   For instance  you re probably familiar with calculators and have probably used quite a few in your days  but most of the time they re all different  You  on the other hand  knows how a standard calculator should work  so you re able to use them all  even if you can t use the specific features that each calculator has that none of the other has   This is the beauty of interfaces  You can write a piece of code  that knows that it will get objects passed to it that it can expect certain behavior from  It doesn t care one hoot what kind of object it is  only that it supports the behavior needed   Let me give you a concrete example   We have a custom-built translation system for windows forms  This system loops through controls on a form and translate text in each  The system knows how to handle basic controls  like the-type-of-control-that-has-a-Text-property  and similar basic stuff  but for anything basic  it falls short   Now  since controls inherit from pre-defined classes that we have no control over  we could do one of three things    Build support for our translation system to detect specifically which type of control it is working with  and translate the correct bits  maintenance nightmare  Build support into base classes  impossible  since all the controls inherit from different pre-defined classes  Add interface support   So we did nr  3  All our controls implement ILocalizable  which is an interface that gives us one method  the ability to translate  itself  into a container of translation text rules  As such  the form doesn t need to know which kind of control it has found  only that it implements the specific interface  and knows that there is a method where it can call to localize the control

User · Answer

There are some wonderful answers on here to this questions that get into all sorts of great detail about interfaces and loosely coupling code  inversion of control and so on   There are some fairly heady discussions  so I d like to take the opportunity to break things down a bit for understanding why an interface is useful   When I first started getting exposed to interfaces  I too was confused about their relevance   I didn t understand why you needed them   If we re using a language like Java or C   we already have inheritance and I viewed interfaces as a weaker form of inheritance and thought   why bother    In a sense I was right  you can think of interfaces as sort of a weak form of inheritance  but beyond that I finally understood their use as a language construct by thinking of them as a means of classifying common traits or behaviors that were exhibited by potentially many non-related classes of objects   For example -- say you have a SIM game and have the following classes   class HouseFly inherits Insect       void FlyAroundYourHead         void LandOnThings        class Telemarketer inherits Person       void CallDuringDinner         void ContinueTalkingWhenYouSayNo         Clearly  these two objects have nothing in common in terms of direct inheritance   But  you could say they are both annoying     Let s say our game needs to have some sort of random thing that annoys the game player when they eat dinner   This could be a HouseFly or a Telemarketer or both -- but how do you allow for both with a single function   And how do you ask each different type of object to  do their annoying thing  in the same way   The key to realize is that both a Telemarketer and HouseFly share a common loosely interpreted behavior even though they are nothing alike in terms of modeling them   So  let s make an interface that both can implement   interface IPest       void BeAnnoying       class HouseFly inherits Insect implements IPest       void FlyAroundYourHead         void LandOnThings          void BeAnnoying             FlyAroundYourHead            LandOnThings             class Telemarketer inherits Person implements IPest       void CallDuringDinner         void ContinueTalkingWhenYouSayNo          void BeAnnoying             CallDuringDinner            ContinueTalkingWhenYouSayNo              We now have two classes that can each be annoying in their own way   And they do not need to derive from the same base class and share common inherent characteristics -- they simply need to satisfy the contract of IPest -- that contract is simple   You just have to BeAnnoying   In this regard  we can model the following   class DiningRoom        DiningRoom Person   diningPeople  IPest   pests               void ServeDinner             when diningPeople are eating           foreach pest in pests         pest BeAnnoying              Here we have a dining room that accepts a number of diners and a number of pests -- note the use of the interface   This means that in our little world  a member of the pests array could actually be a Telemarketer object or a HouseFly object   The ServeDinner method is called when dinner is served and our people in the dining room are supposed to eat   In our little game  that s when our pests do their work -- each pest is instructed to be annoying by way of the IPest interface   In this way  we can easily have both Telemarketers and HouseFlys be annoying in each of their own ways -- we care only that we have something in the DiningRoom object that is a pest  we don t really care what it is and they could have nothing in common with other     This very contrived pseudo-code example  that dragged on a lot longer than I anticipated  is simply meant to illustrate the kind of thing that finally turned the light on for me in terms of when we might use an interface   I apologize in advance for the silliness of the example  but hope that it helps in your understanding   And  to be sure  the other posted answers you ve received here really cover the gamut of the use of interfaces today in design patterns and development methodologies

User · Answer

There are some wonderful answers on here to this questions that get into all sorts of great detail about interfaces and loosely coupling code  inversion of control and so on   There are some fairly heady discussions  so I d like to take the opportunity to break things down a bit for understanding why an interface is useful   When I first started getting exposed to interfaces  I too was confused about their relevance   I didn t understand why you needed them   If we re using a language like Java or C   we already have inheritance and I viewed interfaces as a weaker form of inheritance and thought   why bother    In a sense I was right  you can think of interfaces as sort of a weak form of inheritance  but beyond that I finally understood their use as a language construct by thinking of them as a means of classifying common traits or behaviors that were exhibited by potentially many non-related classes of objects   For example -- say you have a SIM game and have the following classes   class HouseFly inherits Insect       void FlyAroundYourHead         void LandOnThings        class Telemarketer inherits Person       void CallDuringDinner         void ContinueTalkingWhenYouSayNo         Clearly  these two objects have nothing in common in terms of direct inheritance   But  you could say they are both annoying     Let s say our game needs to have some sort of random thing that annoys the game player when they eat dinner   This could be a HouseFly or a Telemarketer or both -- but how do you allow for both with a single function   And how do you ask each different type of object to  do their annoying thing  in the same way   The key to realize is that both a Telemarketer and HouseFly share a common loosely interpreted behavior even though they are nothing alike in terms of modeling them   So  let s make an interface that both can implement   interface IPest       void BeAnnoying       class HouseFly inherits Insect implements IPest       void FlyAroundYourHead         void LandOnThings          void BeAnnoying             FlyAroundYourHead            LandOnThings             class Telemarketer inherits Person implements IPest       void CallDuringDinner         void ContinueTalkingWhenYouSayNo          void BeAnnoying             CallDuringDinner            ContinueTalkingWhenYouSayNo              We now have two classes that can each be annoying in their own way   And they do not need to derive from the same base class and share common inherent characteristics -- they simply need to satisfy the contract of IPest -- that contract is simple   You just have to BeAnnoying   In this regard  we can model the following   class DiningRoom        DiningRoom Person   diningPeople  IPest   pests               void ServeDinner             when diningPeople are eating           foreach pest in pests         pest BeAnnoying              Here we have a dining room that accepts a number of diners and a number of pests -- note the use of the interface   This means that in our little world  a member of the pests array could actually be a Telemarketer object or a HouseFly object   The ServeDinner method is called when dinner is served and our people in the dining room are supposed to eat   In our little game  that s when our pests do their work -- each pest is instructed to be annoying by way of the IPest interface   In this way  we can easily have both Telemarketers and HouseFlys be annoying in each of their own ways -- we care only that we have something in the DiningRoom object that is a pest  we don t really care what it is and they could have nothing in common with other     This very contrived pseudo-code example  that dragged on a lot longer than I anticipated  is simply meant to illustrate the kind of thing that finally turned the light on for me in terms of when we might use an interface   I apologize in advance for the silliness of the example  but hope that it helps in your understanding   And  to be sure  the other posted answers you ve received here really cover the gamut of the use of interfaces today in design patterns and development methodologies

User · Answer

Using interfaces is a key factor in making your code easily testable in addition to removing unnecessary couplings between your classes   By creating an interface that defines the operations on your class  you allow classes that want to use that functionality the ability to use it without depending on your implementing class directly   If later on you decide to change and use a different implementation  you need only change the part of the code where the implementation is instantiated   The rest of the code need not change because it depends on the interface  not the implementing class   This is very useful in creating unit tests   In the class under test you have it depend on the interface and inject an instance of the interface into the class  or a factory that allows it to build instances of the interface as needed  via the constructor or a property settor   The class uses the provided  or created  interface in its methods   When you go to write your tests  you can mock or fake the interface and provide an interface that responds with data configured in your unit test   You can do this because your class under test deals only with the interface  not your concrete implementation   Any class implementing the interface  including your mock or fake class  will do   EDIT  Below is a link to an article where Erich Gamma discusses his quote   Program to an interface  not an implementation    http   www artima com lejava articles designprinciples html

User · Answer

In addition to the already selected answer  and the various informative posts here   I would highly recommend grabbing a copy of Head First Design Patterns   It is a very easy read and will answer your question directly  explain why it is important  and show you many programming patterns you can use to make use of that principle  and others

User · Answer

Programming to an interface is saying   I need this functionality and I don t care where it comes from    Consider  in Java   the List interface versus the ArrayList and LinkedList concrete classes  If all I care about is that I have a data structure containing multiple data items that I should access via iteration  I d pick a List  and that s 99  of the time   If I know that I need constant-time insert delete from either end of the list  I might pick the LinkedList concrete implementation  or more likely  use the Queue interface   If I know I need random access by index  I d pick the ArrayList concrete class

User · Answer

To add to the existing posts  sometimes coding to interfaces helps on large projects when developers work on separate components simultaneously  All you need is to define interfaces upfront and write code to them while other developers write code to the interface you are implementing

User · Answer

It can be advantageous to program to interfaces  even when we are not depending on abstractions   Programming to interfaces forces us to use a contextually appropriate subset of an object  That helps because it     prevents us from doing contextually inappropriate things  and  lets us safely change the implementation in the future    For example  consider a Person class that implements the Friend and the Employee interface   class Person implements AbstractEmployee  AbstractFriend       In the context of the person s birthday  we program to the Friend interface  to prevent treating the person like an Employee   function party         const friend  Friend   new Person  Kathryn        friend HaveFun        In the context of the person s work  we program to the Employee interface  to prevent blurring workplace boundaries   function workplace         const employee  Employee   new Person  Kathryn        employee DoWork        Great  We have behaved appropriately in different contexts  and our software is working well   Far into the future  if our business changes to work with dogs  we can change the software fairly easily  First  we create a Dog class that implements both Friend and Employee  Then  we safely change new Person   to new Dog    Even if both functions have thousands of lines of code  that simple edit will work because we know the following are true    Function party uses only the Friend subset of Person  Function workplace uses only the Employee subset of Person  Class Dog implements both the Friend and Employee interfaces    On the other hand  if either party or workplace were to have programmed against Person  there would be a risk of both having Person-specific code  Changing from Person to Dog would require us to comb through the code to extirpate any Person-specific code that Dog does not support   The moral  programming to interfaces helps our code to behave appropriately and to be ready for change  It also prepares our code to depend on abstractions  which brings even more advantages

User · Answer

The specific example I used to give to students is that they should write  List myList   new ArrayList       programming to the List interface   instead of  ArrayList myList   new ArrayList       this is bad   These look exactly the same in a short program  but if you go on to use myList 100 times in your program you can start to see a difference   The first declaration ensures that you only call methods on myList that are defined by the List interface  so no ArrayList specific methods    If you ve programmed to the interface this way  later on you can decide that you really need  List myList   new TreeList      and you only have to change your code in that one spot   You already know that the rest of your code doesn t do anything that will be broken by changing the implementation because you programmed to the interface   The benefits are even more obvious  I think  when you re talking about method parameters and return values   Take this for example   public ArrayList doSomething HashMap map     That method declaration ties you to two concrete implementations  ArrayList and HashMap   As soon as that method is called from other code  any changes to those types probably mean you re going to have to change the calling code as well  It would be better to program to the interfaces   public List doSomething Map map     Now it doesn t matter what kind of List you return  or what kind of Map is passed in as a parameter  Changes that you make inside the doSomething method won t force you to change the calling code

User · Answer

Here is a simple example to illustrate when you program a flight booking system     This interface is very flexible and abstract     addPassenger Plane seat  Ticket ticket       Boeing is implementation of Plane     addPassenger Boeing747 seat  EconomyTicket ticket        addPassenger Cessna  BusinessClass ticket         addPassenger J15  E87687

User · Answer

So  just to get this right  the advantage of a interface is that I can separate the calling of a method from any particular class  Instead creating a instance of the interface  where the implementation is given from whichever class I choose that implements that interface  Thus allowing me to have many classes  which have similar but slightly different functionality and in some cases  the cases related to the intention of the interface  not care which object it is   For example  I could have a movement interface  A method which makes something  move  and any object  Person  Car  Cat  that implements the movement interface could be passed in and told to move  Without the method every knowing the type of class it is

User · Answer

So  just to get this right  the advantage of a interface is that I can separate the calling of a method from any particular class  Instead creating a instance of the interface  where the implementation is given from whichever class I choose that implements that interface  Thus allowing me to have many classes  which have similar but slightly different functionality and in some cases  the cases related to the intention of the interface  not care which object it is   For example  I could have a movement interface  A method which makes something  move  and any object  Person  Car  Cat  that implements the movement interface could be passed in and told to move  Without the method every knowing the type of class it is

User · Answer

If I m writing a new class Swimmer to add the functionality swim   and need to use an object of class say Dog  and this Dog class implements interface Animal which declares swim     At the top of the hierarchy  Animal   it s very abstract while at the bottom  Dog  it s very concrete  The way I think about  programming to interfaces  is that  as I write Swimmer class  I want to write my code against the interface that s as far up that hierarchy which in this case is an Animal object  An interface is free from implementation details and thus makes your code loosely-coupled   The implementation details can be changed with time  however  it would not affect the remaining code since all you are interacting with is with the interface and not the implementation  You don t care what the implementation is like    all you know is that there will be a class that would implement the interface

User · Answer

To add to the existing posts  sometimes coding to interfaces helps on large projects when developers work on separate components simultaneously  All you need is to define interfaces upfront and write code to them while other developers write code to the interface you are implementing

User · Answer

Short story  A postman is asked to go home after home and receive the covers contains  letters  documents  cheques  gift cards  application  love letter  with the address written on it to deliver   Suppose there is no cover and ask the postman to go home after home and receive all the things and deliver to other people  the postman can get confused   So better wrap it with cover  in our story it is the interface  then he will do his job fine   Now the postman s job is to receive and deliver the covers only  he wouldn t bothered what is inside in the cover    Create a type of interface not actual type  but implement it with actual type   To create to interface means your components get Fit into the rest of code easily  I give you an example   you have the AirPlane interface as below   interface Airplane      parkPlane        servicePlane        Suppose you have methods in your Controller class of Planes like  parkPlane Airplane plane    and  servicePlane Airplane plane    implemented in your program  It will not BREAK your code  I mean  it need not to change as long as it accepts arguments as AirPlane   Because it will accept any Airplane despite actual type  flyer  highflyr  fighter  etc   Also  in a collection   List lt Airplane gt  plane     Will take all your planes   The following example will clear your understanding     You have a fighter plane that implements it  so  public class Fighter implements Airplane        public void  parkPlane               Specific implementations for fighter plane to park           public void  servicePlane               Specific implementatoins for fighter plane to service            The same thing for HighFlyer and other clasess   public class HighFlyer implements Airplane        public void  parkPlane               Specific implementations for HighFlyer plane to park            public void  servicePlane               specific implementatoins for HighFlyer plane to service            Now think your controller classes using AirPlane several times   Suppose your Controller class is ControlPlane like below   public Class ControlPlane    AirPlane plane      so much method with AirPlane reference are used here        Here magic comes as you may make your new AirPlane type instances as many as you want and you are not changing the code of ControlPlane class   You can add an instance     JumboJetPlane    implementing AirPlane interface  AirBus           implementing AirPlane interface    You may remove instances of previously created types too

User · Answer

It sounds like you understand how interfaces work but are unsure of when to use them and what advantages they offer  Here are a few examples of when an interface would make sense      if I want to add search capabilities to my application and support multiple search    engines such as Google  Yahoo  Live  etc   interface ISearchProvider       string Search string keywords       then I could create GoogleSearchProvider  YahooSearchProvider  LiveSearchProvider  etc      if I want to support multiple downloads using different protocols    HTTP  HTTPS  FTP  FTPS  etc  interface IUrlDownload       void Download string url        how about an image loader for different kinds of images JPG  GIF  PNG  etc  interface IImageLoader       Bitmap LoadImage string filename      then create JpegImageLoader  GifImageLoader  PngImageLoader  etc   Most add-ins and plugin systems work off interfaces   Another popular use is for the Repository pattern  Say I want to load a list of zip codes from different sources  interface IZipCodeRepository       IList lt ZipCode gt  GetZipCodes string state       then I could create an XMLZipCodeRepository  SQLZipCodeRepository  CSVZipCodeRepository  etc  For my web applications  I often create XML repositories early on so I can get something up and running before the SQL Database is ready  Once the database is ready I write an SQLRepository to replace the XML version  The rest of my code remains unchanged since it runs solely off of interfaces   Methods can accept interfaces such as   PrintZipCodes IZipCodeRepository zipCodeRepository  string state        foreach  ZipCode zipCode in zipCodeRepository GetZipCodes state                 Console WriteLine zipCode ToString

User · Answer

program to an interface is a term from the GOF book  i would not directly say it has to do with java interface but rather real interfaces   to achieve clean layer separation  you need to create some separation between systems for example   Let s say you had a concrete database you want to use  you would never  program to the database     instead you would  program to the storage interface   Likewise you would never  program to a Web Service  but rather you would program to a  client interface    this is so you can easily swap things out    i find these rules help me    1  we use a java interface when we have multiple types of an object  if i just have single object  i dont see the point  if there are at least two concrete implementations of some idea  then i  would use a java  interface    2  if as i stated above  you want to bring decoupling from an external system  storage system  to your own system  local DB  then also  use a interface    notice how there are two ways to consider when to use them  hope this helps

User · Answer

Short story  A postman is asked to go home after home and receive the covers contains  letters  documents  cheques  gift cards  application  love letter  with the address written on it to deliver   Suppose there is no cover and ask the postman to go home after home and receive all the things and deliver to other people  the postman can get confused   So better wrap it with cover  in our story it is the interface  then he will do his job fine   Now the postman s job is to receive and deliver the covers only  he wouldn t bothered what is inside in the cover    Create a type of interface not actual type  but implement it with actual type   To create to interface means your components get Fit into the rest of code easily  I give you an example   you have the AirPlane interface as below   interface Airplane      parkPlane        servicePlane        Suppose you have methods in your Controller class of Planes like  parkPlane Airplane plane    and  servicePlane Airplane plane    implemented in your program  It will not BREAK your code  I mean  it need not to change as long as it accepts arguments as AirPlane   Because it will accept any Airplane despite actual type  flyer  highflyr  fighter  etc   Also  in a collection   List lt Airplane gt  plane     Will take all your planes   The following example will clear your understanding     You have a fighter plane that implements it  so  public class Fighter implements Airplane        public void  parkPlane               Specific implementations for fighter plane to park           public void  servicePlane               Specific implementatoins for fighter plane to service            The same thing for HighFlyer and other clasess   public class HighFlyer implements Airplane        public void  parkPlane               Specific implementations for HighFlyer plane to park            public void  servicePlane               specific implementatoins for HighFlyer plane to service            Now think your controller classes using AirPlane several times   Suppose your Controller class is ControlPlane like below   public Class ControlPlane    AirPlane plane      so much method with AirPlane reference are used here        Here magic comes as you may make your new AirPlane type instances as many as you want and you are not changing the code of ControlPlane class   You can add an instance     JumboJetPlane    implementing AirPlane interface  AirBus           implementing AirPlane interface    You may remove instances of previously created types too

User · Answer

So  just to get this right  the advantage of a interface is that I can separate the calling of a method from any particular class  Instead creating a instance of the interface  where the implementation is given from whichever class I choose that implements that interface  Thus allowing me to have many classes  which have similar but slightly different functionality and in some cases  the cases related to the intention of the interface  not care which object it is   For example  I could have a movement interface  A method which makes something  move  and any object  Person  Car  Cat  that implements the movement interface could be passed in and told to move  Without the method every knowing the type of class it is

User · Answer

Imagine you have a product called  Zebra  that can be extended by plugins  It finds the plugins by searching for DLLs in some directory  It loads all those DLLs and uses reflection to find any classes that implement IZebraPlugin  and then calls the methods of that interface to communicate with the plugins    This makes it completely independent of any specific plugin class - it doesn t care what the classes are  It only cares that they fulfill the interface specification    Interfaces are a way of defining points of extensibility like this  Code that talks to an interface is more loosely coupled - in fact it is not coupled at all to any other specific code  It can inter-operate with plugins written years later by people who have never met the original developer   You could instead use a base class with virtual functions - all plugins would be derived from the base class  But this is much more limiting because a class can only have one base class  whereas it can implement any number of interfaces

User · Answer

It makes your code a lot more extensible and easier to maintain when you have sets of similar classes   I am a junior programmer  so I am no expert  but I just finished a project that required something similar   I work on client side software that talks to a server running a medical device   We are developing a new version of this device that has some new components that the customer must configure at times   There are two types of new components  and they are different  but they are also very similar   Basically  I had to create two config forms  two lists classes  two of everything     I decided that it would be best to create an abstract base class for each control type that would hold almost all of the real logic  and then derived types to take care of the differences between the two components   However  the base classes would not have been able to perform operations on these components if I had to worry about types all of the time  well  they could have  but there would have been an  if  statement or switch in every method    I defined a simple interface for these components and all of the base classes talk to this interface   Now when I change something  it pretty much  just works  everywhere and I have no code duplication

User · Answer

In Java these concrete classes all implement the CharSequence interface      CharBuffer  String  StringBuffer  StringBuilder   These concrete classes do not have a common parent class other than Object  so there is nothing that relates them  other than the fact they each have something to do with arrays of characters  representing such  or manipulating such  For instance  the characters of String cannot be changed once a String object is instantiated  whereas the characters of StringBuffer or StringBuilder can be edited   Yet each one of these classes is capable of suitably implementing the CharSequence interface methods   char charAt int index  int length   CharSequence subSequence int start  int end  String toString     In some cases  Java class library classes that used to accept String have been revised to now accept the CharSequence interface  So if you have an instance of StringBuilder  instead of extracting a String object  which means instantiating a new object instance   it can instead just pass the StringBuilder itself as it implements the CharSequence interface   The Appendable interface that some classes implement has much the same kind of benefit for any situation where characters can be appended to an instance of the underlying concrete class object instance  All of these concrete classes implement the Appendable interface      BufferedWriter  CharArrayWriter  CharBuffer  FileWriter  FilterWriter  LogStream  OutputStreamWriter  PipedWriter  PrintStream  PrintWriter  StringBuffer  StringBuilder  StringWriter  Writer

User · Answer

In Java these concrete classes all implement the CharSequence interface      CharBuffer  String  StringBuffer  StringBuilder   These concrete classes do not have a common parent class other than Object  so there is nothing that relates them  other than the fact they each have something to do with arrays of characters  representing such  or manipulating such  For instance  the characters of String cannot be changed once a String object is instantiated  whereas the characters of StringBuffer or StringBuilder can be edited   Yet each one of these classes is capable of suitably implementing the CharSequence interface methods   char charAt int index  int length   CharSequence subSequence int start  int end  String toString     In some cases  Java class library classes that used to accept String have been revised to now accept the CharSequence interface  So if you have an instance of StringBuilder  instead of extracting a String object  which means instantiating a new object instance   it can instead just pass the StringBuilder itself as it implements the CharSequence interface   The Appendable interface that some classes implement has much the same kind of benefit for any situation where characters can be appended to an instance of the underlying concrete class object instance  All of these concrete classes implement the Appendable interface      BufferedWriter  CharArrayWriter  CharBuffer  FileWriter  FilterWriter  LogStream  OutputStreamWriter  PipedWriter  PrintStream  PrintWriter  StringBuffer  StringBuilder  StringWriter  Writer

User · Answer

Programming to an interface has absolutely nothing to do with abstract interfaces like we see in Java or  NET  It isn t even an OOP concept   What it means is don t go messing around with the internals of an object or data structure  Use the Abstract Program Interface  or API  to interact with your data  In Java or C  that means using public properties and methods instead of raw field access  For C that means using functions instead of raw pointers   EDIT  And with databases it means using views and stored procedures instead of direct table access

User · Answer

C   explanation   Think of an interface as your classes public methods   You then could create a template that  depends  on these public methods in order to carry out it s own function  it makes function calls defined in the classes public interface   Lets say this template is a container  like a Vector class  and the interface it depends on is a search algorithm   Any algorithm class that defines the functions interface Vector makes calls to will satisfy the  contract   as someone explained in the original reply   The algorithms don t even need to be of the same base class  the only requirement is that the functions methods that the Vector depends on  interface  is defined in your algorithm   The point of all of this is that you could supply any different search algorithm class just as long as it supplied the interface that Vector depends on  bubble search  sequential search  quick search    You might also want to design other containers  lists  queues  that would harness the same search algorithm as Vector by having them fulfill the interface contract that your search algorithms depends on   This saves time  OOP principle  code reuse   as you are able to write an algorithm once instead of again and again and again specific to every new object you create without over-complicating the issue with an overgrown inheritance tree   As for  missing out  on how things operate  big-time  at least in C     as this is how most of the Standard TEMPLATE Library s framework operates   Of course when using inheritance and abstract classes the methodology of programming to an interface changes  but the principle is the same  your public functions methods are your classes interface   This is a huge topic and one of the the cornerstone principles of Design Patterns

User · Answer

I am a late comer to this question  but I want to mention here that the line  Program to an interface  not an implementation  had some good discussion in the GoF  Gang of Four  Design Patterns book   It stated  on p  18      Program to an interface  not an implementation      Don t declare variables to be instances of particular concrete classes  Instead  commit only to an interface defined by an abstract class  You will find this to be a common theme of the design patterns in this book    and above that  it began with      There are two benefits to manipulating objects solely in terms of the interface defined by abstract classes          Clients remain unaware of the specific types of objects they use  as long as the objects adhere to the interface that clients expect    Clients remain unaware of the classes that implement these objects  Clients only know about the abstract class es  defining the interface       So in other words  don t write it your classes so that it has a quack   method for ducks  and then a bark   method for dogs  because they are too specific for a particular implementation of a class  or subclass    Instead  write the method using names that are general enough to be used in the base class  such as giveSound   or move    so that they can be used for ducks  dogs  or even cars  and then the client of your classes can just say  giveSound   rather than thinking about whether to use quack   or bark   or even determine the type before issuing the correct message to be sent to the object

User · Answer

So  just to get this right  the advantage of a interface is that I can separate the calling of a method from any particular class  Instead creating a instance of the interface  where the implementation is given from whichever class I choose that implements that interface  Thus allowing me to have many classes  which have similar but slightly different functionality and in some cases  the cases related to the intention of the interface  not care which object it is   For example  I could have a movement interface  A method which makes something  move  and any object  Person  Car  Cat  that implements the movement interface could be passed in and told to move  Without the method every knowing the type of class it is

User · Answer

In addition to the already selected answer  and the various informative posts here   I would highly recommend grabbing a copy of Head First Design Patterns   It is a very easy read and will answer your question directly  explain why it is important  and show you many programming patterns you can use to make use of that principle  and others

User · Answer

Programming to Interfaces is awesome  it promotes loose coupling  As  lassevk mentioned  Inversion of Control is a great use of this   In addition  look into SOLID principals  here is a video series  It goes through a hard coded  strongly coupled example  then looks at interfaces  finally progressing to a IoC DI tool  NInject

User · Answer

It is also good for Unit Testing  you can inject your own classes  that meet the requirements of the interface  into a class that depends on it

User · Answer

It makes your code a lot more extensible and easier to maintain when you have sets of similar classes   I am a junior programmer  so I am no expert  but I just finished a project that required something similar   I work on client side software that talks to a server running a medical device   We are developing a new version of this device that has some new components that the customer must configure at times   There are two types of new components  and they are different  but they are also very similar   Basically  I had to create two config forms  two lists classes  two of everything     I decided that it would be best to create an abstract base class for each control type that would hold almost all of the real logic  and then derived types to take care of the differences between the two components   However  the base classes would not have been able to perform operations on these components if I had to worry about types all of the time  well  they could have  but there would have been an  if  statement or switch in every method    I defined a simple interface for these components and all of the base classes talk to this interface   Now when I change something  it pretty much  just works  everywhere and I have no code duplication

User · Answer

It is also good for Unit Testing  you can inject your own classes  that meet the requirements of the interface  into a class that depends on it

User · Answer

In Java these concrete classes all implement the CharSequence interface      CharBuffer  String  StringBuffer  StringBuilder   These concrete classes do not have a common parent class other than Object  so there is nothing that relates them  other than the fact they each have something to do with arrays of characters  representing such  or manipulating such  For instance  the characters of String cannot be changed once a String object is instantiated  whereas the characters of StringBuffer or StringBuilder can be edited   Yet each one of these classes is capable of suitably implementing the CharSequence interface methods   char charAt int index  int length   CharSequence subSequence int start  int end  String toString     In some cases  Java class library classes that used to accept String have been revised to now accept the CharSequence interface  So if you have an instance of StringBuilder  instead of extracting a String object  which means instantiating a new object instance   it can instead just pass the StringBuilder itself as it implements the CharSequence interface   The Appendable interface that some classes implement has much the same kind of benefit for any situation where characters can be appended to an instance of the underlying concrete class object instance  All of these concrete classes implement the Appendable interface      BufferedWriter  CharArrayWriter  CharBuffer  FileWriter  FilterWriter  LogStream  OutputStreamWriter  PipedWriter  PrintStream  PrintWriter  StringBuffer  StringBuilder  StringWriter  Writer

User · Answer

Using interfaces is a key factor in making your code easily testable in addition to removing unnecessary couplings between your classes   By creating an interface that defines the operations on your class  you allow classes that want to use that functionality the ability to use it without depending on your implementing class directly   If later on you decide to change and use a different implementation  you need only change the part of the code where the implementation is instantiated   The rest of the code need not change because it depends on the interface  not the implementing class   This is very useful in creating unit tests   In the class under test you have it depend on the interface and inject an instance of the interface into the class  or a factory that allows it to build instances of the interface as needed  via the constructor or a property settor   The class uses the provided  or created  interface in its methods   When you go to write your tests  you can mock or fake the interface and provide an interface that responds with data configured in your unit test   You can do this because your class under test deals only with the interface  not your concrete implementation   Any class implementing the interface  including your mock or fake class  will do   EDIT  Below is a link to an article where Erich Gamma discusses his quote   Program to an interface  not an implementation    http   www artima com lejava articles designprinciples html

User · Answer

To add to the existing posts  sometimes coding to interfaces helps on large projects when developers work on separate components simultaneously  All you need is to define interfaces upfront and write code to them while other developers write code to the interface you are implementing

User · Answer

An interface is like a contract  where you want your implementation class to implement methods written in the contract  interface   Since Java does not provide multiple inheritance   programming to interface  is a good way to achieve multiple inheritance   If you have a class A that is already extending some other class B  but you want that class A to also follow certain guidelines or implement a certain contract  then you can do so by the  programming to interface  strategy

User · Answer

If you program in Java  JDBC is a good example   JDBC defines a set of interfaces but says nothing about the implementation   Your applications can be written against this set of interfaces   In theory  you pick some JDBC driver and your application would just work   If you discover there s a faster or  better  or cheaper JDBC driver or for whatever reason  you can again in theory re-configure your property file  and without having to make any change in your application  your application would still work

User · Answer

If you program in Java  JDBC is a good example   JDBC defines a set of interfaces but says nothing about the implementation   Your applications can be written against this set of interfaces   In theory  you pick some JDBC driver and your application would just work   If you discover there s a faster or  better  or cheaper JDBC driver or for whatever reason  you can again in theory re-configure your property file  and without having to make any change in your application  your application would still work

User · Answer

Also I see a lot of good and explanatory answers here  so I want to give my point of view here  including some extra information what I noticed when using this method   Unit testing  For the last two years  I have written a hobby project and I did not write unit tests for it  After writing about 50K lines I found out it would be really necessary to write unit tests  I did not use interfaces  or very sparingly      and when I made my first unit test  I found out it was complicated  Why   Because I had to make a lot of class instances  used for input as class variables and or parameters  So the tests look more like integration tests  having to make a complete  framework  of classes since all was tied together    Fear of interfaces So I decided to use interfaces  My fear was that I had to implement all functionality everywhere  in all used classes  multiple times  In some way this is true  however  by using inheritance it can be reduced a lot   Combination of interfaces and inheritance I found out the combination is very good to be used  I give a very simple example   public interface IPricable       int Price   get       public interface ICar   IPricable  public abstract class Article       public int Price   get   return            public class Car   Article  ICar          Price does not need to be defined here     This way copying code is not necessary  while still having the benefit of using a car as interface  ICar

User · Answer

Code to the Interface Not the Implementation has NOTHING to do with Java  nor its Interface construct    This concept was brought to prominence in the Patterns   Gang of Four books but was most probably around well before that  The concept certainly existed well before Java ever existed    The Java Interface construct was created to aid in this idea  among other things   and people have become too focused on the construct as the centre of the meaning rather than the original intent  However  it is the reason we have public and private methods and attributes in Java  C    C   etc   It means just interact with an object or system s public interface  Don t worry or even anticipate how it does what it does internally  Don t worry about how it is implemented  In object-oriented code  it is why we have public vs  private methods attributes  We are intended to use the public methods because the private methods are there only for use internally  within the class  They make up the implementation of the class and can be changed as required without changing the public interface  Assume that regarding functionality  a method on a class will perform the same operation with the same expected result every time you call it with the same parameters  It allows the author to change how the class works  its implementation  without breaking how people interact with it   And you can program to the interface  not the implementation without ever using an Interface construct  You can program to the interface not the implementation in C    which does not have an Interface construct  You can integrate two massive enterprise systems much more robustly as long as they interact through public interfaces  contracts  rather than calling methods on objects internal to the systems  The interfaces are expected to always react the same expected way given the same input parameters  if implemented to the interface and not the implementation  The concept works in many places   Shake the thought that Java Interfaces have anything what-so-ever to do with the concept of  Program to the Interface  Not the Implementation   They can help apply the concept  but they are not the concept

User · Answer

C   explanation   Think of an interface as your classes public methods   You then could create a template that  depends  on these public methods in order to carry out it s own function  it makes function calls defined in the classes public interface   Lets say this template is a container  like a Vector class  and the interface it depends on is a search algorithm   Any algorithm class that defines the functions interface Vector makes calls to will satisfy the  contract   as someone explained in the original reply   The algorithms don t even need to be of the same base class  the only requirement is that the functions methods that the Vector depends on  interface  is defined in your algorithm   The point of all of this is that you could supply any different search algorithm class just as long as it supplied the interface that Vector depends on  bubble search  sequential search  quick search    You might also want to design other containers  lists  queues  that would harness the same search algorithm as Vector by having them fulfill the interface contract that your search algorithms depends on   This saves time  OOP principle  code reuse   as you are able to write an algorithm once instead of again and again and again specific to every new object you create without over-complicating the issue with an overgrown inheritance tree   As for  missing out  on how things operate  big-time  at least in C     as this is how most of the Standard TEMPLATE Library s framework operates   Of course when using inheritance and abstract classes the methodology of programming to an interface changes  but the principle is the same  your public functions methods are your classes interface   This is a huge topic and one of the the cornerstone principles of Design Patterns

User · Answer

Using interfaces is a key factor in making your code easily testable in addition to removing unnecessary couplings between your classes   By creating an interface that defines the operations on your class  you allow classes that want to use that functionality the ability to use it without depending on your implementing class directly   If later on you decide to change and use a different implementation  you need only change the part of the code where the implementation is instantiated   The rest of the code need not change because it depends on the interface  not the implementing class   This is very useful in creating unit tests   In the class under test you have it depend on the interface and inject an instance of the interface into the class  or a factory that allows it to build instances of the interface as needed  via the constructor or a property settor   The class uses the provided  or created  interface in its methods   When you go to write your tests  you can mock or fake the interface and provide an interface that responds with data configured in your unit test   You can do this because your class under test deals only with the interface  not your concrete implementation   Any class implementing the interface  including your mock or fake class  will do   EDIT  Below is a link to an article where Erich Gamma discusses his quote   Program to an interface  not an implementation    http   www artima com lejava articles designprinciples html

User · Answer

It is also good for Unit Testing  you can inject your own classes  that meet the requirements of the interface  into a class that depends on it

User · Answer

Q  -      quot Could you use any class that implements an interface  quot  A  - Yes  Q  -      quot When would you need to do that  quot  A  - Each time you need a class es  that implements interface s    Note  We couldn t instantiate an interface not implemented by a class - True   Why  Because the interface has only method prototypes  not definitions  just functions names  not their logic    AnIntf anInst   new Aclass       we could do this only if Aclass implements AnIntf     anInst will have Aclass reference    Note  Now we could understand what happened if Bclass and Cclass implemented same Dintf  Dintf bInst   new Bclass         now we could call all Dintf functions implemented  defined  in Bclass   Dintf cInst   new Cclass         now we could call all Dintf functions implemented  defined  in Cclass   What we have  Same interface prototypes  functions names in interface   and call different implementations  Bibliography  Prototypes - wikipedia

User · Answer

In addition to the already selected answer  and the various informative posts here   I would highly recommend grabbing a copy of Head First Design Patterns   It is a very easy read and will answer your question directly  explain why it is important  and show you many programming patterns you can use to make use of that principle  and others

User · Answer

It makes your code a lot more extensible and easier to maintain when you have sets of similar classes   I am a junior programmer  so I am no expert  but I just finished a project that required something similar   I work on client side software that talks to a server running a medical device   We are developing a new version of this device that has some new components that the customer must configure at times   There are two types of new components  and they are different  but they are also very similar   Basically  I had to create two config forms  two lists classes  two of everything     I decided that it would be best to create an abstract base class for each control type that would hold almost all of the real logic  and then derived types to take care of the differences between the two components   However  the base classes would not have been able to perform operations on these components if I had to worry about types all of the time  well  they could have  but there would have been an  if  statement or switch in every method    I defined a simple interface for these components and all of the base classes talk to this interface   Now when I change something  it pretty much  just works  everywhere and I have no code duplication

User · Answer

The specific example I used to give to students is that they should write  List myList   new ArrayList       programming to the List interface   instead of  ArrayList myList   new ArrayList       this is bad   These look exactly the same in a short program  but if you go on to use myList 100 times in your program you can start to see a difference   The first declaration ensures that you only call methods on myList that are defined by the List interface  so no ArrayList specific methods    If you ve programmed to the interface this way  later on you can decide that you really need  List myList   new TreeList      and you only have to change your code in that one spot   You already know that the rest of your code doesn t do anything that will be broken by changing the implementation because you programmed to the interface   The benefits are even more obvious  I think  when you re talking about method parameters and return values   Take this for example   public ArrayList doSomething HashMap map     That method declaration ties you to two concrete implementations  ArrayList and HashMap   As soon as that method is called from other code  any changes to those types probably mean you re going to have to change the calling code as well  It would be better to program to the interfaces   public List doSomething Map map     Now it doesn t matter what kind of List you return  or what kind of Map is passed in as a parameter  Changes that you make inside the doSomething method won t force you to change the calling code

User · Answer

I strongly believe hard questions should be explained with easy real-world answers  And in the realm of software design  it s very important   Look at any door in your house  school  church    any building    Imagine some doors got the perils right-bottom  so you have to bow to interact with the door  which is open or close it     Or others got just in the top-left  So  some dwarfs  people with disabilities  or Kevin Hart will not find very amusing and usable such doors     So design is the keyword  create programs to others humans can develop use it   What Interfaces does is to make things easy for other junior senior developers across colossus projects 1   so everybody knows what are they doing with little help from others so you can work as smooth as possible  in Theory       1   How  By exposing the shape of value  So  you don t need documentation  cause the code itself is self-explanatory  Awesome      This answer was not meant to be for language-specific instead of concept-driven  After all  humans are creating tools by writing code

User · Answer

Program to an interface allows to change implementation of contract defined by interface seamlessly  It allows loose coupling between contract and specific implementations   IInterface classRef   new ObjectWhatever   You could use any class that implements IInterface  When would you need to do that   Have a look at this SE question for good example  Why should the interface for a Java class be preferred   does using an Interface hit performance  if so how much   Yes  It will have slight performance overhead in sub-seconds  But if your application has requirement to change the implementation of interface dynamically  don t worry about performance impact   how can you avoid it without having to maintain two bits of code   Don t try to avoid multiple implementations of interface if your application need them  In absence of tight coupling of interface with one specific implementation   you may have to deploy the patch to change one implementation to other implementation  One good use case  Implementation of Strategy pattern  Real World Example of the Strategy Pattern

User · Answer

It makes your code a lot more extensible and easier to maintain when you have sets of similar classes   I am a junior programmer  so I am no expert  but I just finished a project that required something similar   I work on client side software that talks to a server running a medical device   We are developing a new version of this device that has some new components that the customer must configure at times   There are two types of new components  and they are different  but they are also very similar   Basically  I had to create two config forms  two lists classes  two of everything     I decided that it would be best to create an abstract base class for each control type that would hold almost all of the real logic  and then derived types to take care of the differences between the two components   However  the base classes would not have been able to perform operations on these components if I had to worry about types all of the time  well  they could have  but there would have been an  if  statement or switch in every method    I defined a simple interface for these components and all of the base classes talk to this interface   Now when I change something  it pretty much  just works  everywhere and I have no code duplication

User · Answer

You should look into Inversion of Control    Martin Fowler  Inversion of Control Containers and the Dependency Injection pattern Wikipedia  Inversion of Control   In such a scenario  you wouldn t write this   IInterface classRef   new ObjectWhatever      You would write something like this   IInterface classRef   container Resolve lt IInterface gt       This would go into a rule-based setup in the container object  and construct the actual object for you  which could be ObjectWhatever  The important thing is that you could replace this rule with something that used another type of object altogether  and your code would still work   If we leave IoC off the table  you can write code that knows that it can talk to an object that does something specific  but not which type of object or how it does it   This would come in handy when passing parameters   As for your parenthesized question  Also  how could you write a method that takes in an object that implements an Interface  Is that possible    in C  you would simply use the interface type for the parameter type  like this   public void DoSomethingToAnObject IInterface whatever            This plugs right into the  talk to an object that does something specific   The method defined above knows what to expect from the object  that it implements everything in IInterface  but it doesn t care which type of object it is  only that it adheres to the contract  which is what an interface is   For instance  you re probably familiar with calculators and have probably used quite a few in your days  but most of the time they re all different  You  on the other hand  knows how a standard calculator should work  so you re able to use them all  even if you can t use the specific features that each calculator has that none of the other has   This is the beauty of interfaces  You can write a piece of code  that knows that it will get objects passed to it that it can expect certain behavior from  It doesn t care one hoot what kind of object it is  only that it supports the behavior needed   Let me give you a concrete example   We have a custom-built translation system for windows forms  This system loops through controls on a form and translate text in each  The system knows how to handle basic controls  like the-type-of-control-that-has-a-Text-property  and similar basic stuff  but for anything basic  it falls short   Now  since controls inherit from pre-defined classes that we have no control over  we could do one of three things    Build support for our translation system to detect specifically which type of control it is working with  and translate the correct bits  maintenance nightmare  Build support into base classes  impossible  since all the controls inherit from different pre-defined classes  Add interface support   So we did nr  3  All our controls implement ILocalizable  which is an interface that gives us one method  the ability to translate  itself  into a container of translation text rules  As such  the form doesn t need to know which kind of control it has found  only that it implements the specific interface  and knows that there is a method where it can call to localize the control

User · Answer

You should look into Inversion of Control    Martin Fowler  Inversion of Control Containers and the Dependency Injection pattern Wikipedia  Inversion of Control   In such a scenario  you wouldn t write this   IInterface classRef   new ObjectWhatever      You would write something like this   IInterface classRef   container Resolve lt IInterface gt       This would go into a rule-based setup in the container object  and construct the actual object for you  which could be ObjectWhatever  The important thing is that you could replace this rule with something that used another type of object altogether  and your code would still work   If we leave IoC off the table  you can write code that knows that it can talk to an object that does something specific  but not which type of object or how it does it   This would come in handy when passing parameters   As for your parenthesized question  Also  how could you write a method that takes in an object that implements an Interface  Is that possible    in C  you would simply use the interface type for the parameter type  like this   public void DoSomethingToAnObject IInterface whatever            This plugs right into the  talk to an object that does something specific   The method defined above knows what to expect from the object  that it implements everything in IInterface  but it doesn t care which type of object it is  only that it adheres to the contract  which is what an interface is   For instance  you re probably familiar with calculators and have probably used quite a few in your days  but most of the time they re all different  You  on the other hand  knows how a standard calculator should work  so you re able to use them all  even if you can t use the specific features that each calculator has that none of the other has   This is the beauty of interfaces  You can write a piece of code  that knows that it will get objects passed to it that it can expect certain behavior from  It doesn t care one hoot what kind of object it is  only that it supports the behavior needed   Let me give you a concrete example   We have a custom-built translation system for windows forms  This system loops through controls on a form and translate text in each  The system knows how to handle basic controls  like the-type-of-control-that-has-a-Text-property  and similar basic stuff  but for anything basic  it falls short   Now  since controls inherit from pre-defined classes that we have no control over  we could do one of three things    Build support for our translation system to detect specifically which type of control it is working with  and translate the correct bits  maintenance nightmare  Build support into base classes  impossible  since all the controls inherit from different pre-defined classes  Add interface support   So we did nr  3  All our controls implement ILocalizable  which is an interface that gives us one method  the ability to translate  itself  into a container of translation text rules  As such  the form doesn t need to know which kind of control it has found  only that it implements the specific interface  and knows that there is a method where it can call to localize the control

User · Answer

Program to interface  means don t provide hard code right the way  meaning your code should be extended without breaking the previous functionality  Just extensions  not editing the previous code

User · Answer

Imagine you have a product called  Zebra  that can be extended by plugins  It finds the plugins by searching for DLLs in some directory  It loads all those DLLs and uses reflection to find any classes that implement IZebraPlugin  and then calls the methods of that interface to communicate with the plugins    This makes it completely independent of any specific plugin class - it doesn t care what the classes are  It only cares that they fulfill the interface specification    Interfaces are a way of defining points of extensibility like this  Code that talks to an interface is more loosely coupled - in fact it is not coupled at all to any other specific code  It can inter-operate with plugins written years later by people who have never met the original developer   You could instead use a base class with virtual functions - all plugins would be derived from the base class  But this is much more limiting because a class can only have one base class  whereas it can implement any number of interfaces

User · Answer

An interface is like a contract  where you want your implementation class to implement methods written in the contract  interface   Since Java does not provide multiple inheritance   programming to interface  is a good way to achieve multiple inheritance   If you have a class A that is already extending some other class B  but you want that class A to also follow certain guidelines or implement a certain contract  then you can do so by the  programming to interface  strategy

User · Answer

Programming to Interfaces is awesome  it promotes loose coupling  As  lassevk mentioned  Inversion of Control is a great use of this   In addition  look into SOLID principals  here is a video series  It goes through a hard coded  strongly coupled example  then looks at interfaces  finally progressing to a IoC DI tool  NInject

User · Answer

It sounds like you understand how interfaces work but are unsure of when to use them and what advantages they offer  Here are a few examples of when an interface would make sense      if I want to add search capabilities to my application and support multiple search    engines such as Google  Yahoo  Live  etc   interface ISearchProvider       string Search string keywords       then I could create GoogleSearchProvider  YahooSearchProvider  LiveSearchProvider  etc      if I want to support multiple downloads using different protocols    HTTP  HTTPS  FTP  FTPS  etc  interface IUrlDownload       void Download string url        how about an image loader for different kinds of images JPG  GIF  PNG  etc  interface IImageLoader       Bitmap LoadImage string filename      then create JpegImageLoader  GifImageLoader  PngImageLoader  etc   Most add-ins and plugin systems work off interfaces   Another popular use is for the Repository pattern  Say I want to load a list of zip codes from different sources  interface IZipCodeRepository       IList lt ZipCode gt  GetZipCodes string state       then I could create an XMLZipCodeRepository  SQLZipCodeRepository  CSVZipCodeRepository  etc  For my web applications  I often create XML repositories early on so I can get something up and running before the SQL Database is ready  Once the database is ready I write an SQLRepository to replace the XML version  The rest of my code remains unchanged since it runs solely off of interfaces   Methods can accept interfaces such as   PrintZipCodes IZipCodeRepository zipCodeRepository  string state        foreach  ZipCode zipCode in zipCodeRepository GetZipCodes state                 Console WriteLine zipCode ToString

User · Answer

It sounds like you understand how interfaces work but are unsure of when to use them and what advantages they offer  Here are a few examples of when an interface would make sense      if I want to add search capabilities to my application and support multiple search    engines such as Google  Yahoo  Live  etc   interface ISearchProvider       string Search string keywords       then I could create GoogleSearchProvider  YahooSearchProvider  LiveSearchProvider  etc      if I want to support multiple downloads using different protocols    HTTP  HTTPS  FTP  FTPS  etc  interface IUrlDownload       void Download string url        how about an image loader for different kinds of images JPG  GIF  PNG  etc  interface IImageLoader       Bitmap LoadImage string filename      then create JpegImageLoader  GifImageLoader  PngImageLoader  etc   Most add-ins and plugin systems work off interfaces   Another popular use is for the Repository pattern  Say I want to load a list of zip codes from different sources  interface IZipCodeRepository       IList lt ZipCode gt  GetZipCodes string state       then I could create an XMLZipCodeRepository  SQLZipCodeRepository  CSVZipCodeRepository  etc  For my web applications  I often create XML repositories early on so I can get something up and running before the SQL Database is ready  Once the database is ready I write an SQLRepository to replace the XML version  The rest of my code remains unchanged since it runs solely off of interfaces   Methods can accept interfaces such as   PrintZipCodes IZipCodeRepository zipCodeRepository  string state        foreach  ZipCode zipCode in zipCodeRepository GetZipCodes state                 Console WriteLine zipCode ToString

User · Answer

Using interfaces is a key factor in making your code easily testable in addition to removing unnecessary couplings between your classes   By creating an interface that defines the operations on your class  you allow classes that want to use that functionality the ability to use it without depending on your implementing class directly   If later on you decide to change and use a different implementation  you need only change the part of the code where the implementation is instantiated   The rest of the code need not change because it depends on the interface  not the implementing class   This is very useful in creating unit tests   In the class under test you have it depend on the interface and inject an instance of the interface into the class  or a factory that allows it to build instances of the interface as needed  via the constructor or a property settor   The class uses the provided  or created  interface in its methods   When you go to write your tests  you can mock or fake the interface and provide an interface that responds with data configured in your unit test   You can do this because your class under test deals only with the interface  not your concrete implementation   Any class implementing the interface  including your mock or fake class  will do   EDIT  Below is a link to an article where Erich Gamma discusses his quote   Program to an interface  not an implementation    http   www artima com lejava articles designprinciples html

User · Answer

Also I see a lot of good and explanatory answers here  so I want to give my point of view here  including some extra information what I noticed when using this method   Unit testing  For the last two years  I have written a hobby project and I did not write unit tests for it  After writing about 50K lines I found out it would be really necessary to write unit tests  I did not use interfaces  or very sparingly      and when I made my first unit test  I found out it was complicated  Why   Because I had to make a lot of class instances  used for input as class variables and or parameters  So the tests look more like integration tests  having to make a complete  framework  of classes since all was tied together    Fear of interfaces So I decided to use interfaces  My fear was that I had to implement all functionality everywhere  in all used classes  multiple times  In some way this is true  however  by using inheritance it can be reduced a lot   Combination of interfaces and inheritance I found out the combination is very good to be used  I give a very simple example   public interface IPricable       int Price   get       public interface ICar   IPricable  public abstract class Article       public int Price   get   return            public class Car   Article  ICar          Price does not need to be defined here     This way copying code is not necessary  while still having the benefit of using a car as interface  ICar

User · Answer

There are some wonderful answers on here to this questions that get into all sorts of great detail about interfaces and loosely coupling code  inversion of control and so on   There are some fairly heady discussions  so I d like to take the opportunity to break things down a bit for understanding why an interface is useful   When I first started getting exposed to interfaces  I too was confused about their relevance   I didn t understand why you needed them   If we re using a language like Java or C   we already have inheritance and I viewed interfaces as a weaker form of inheritance and thought   why bother    In a sense I was right  you can think of interfaces as sort of a weak form of inheritance  but beyond that I finally understood their use as a language construct by thinking of them as a means of classifying common traits or behaviors that were exhibited by potentially many non-related classes of objects   For example -- say you have a SIM game and have the following classes   class HouseFly inherits Insect       void FlyAroundYourHead         void LandOnThings        class Telemarketer inherits Person       void CallDuringDinner         void ContinueTalkingWhenYouSayNo         Clearly  these two objects have nothing in common in terms of direct inheritance   But  you could say they are both annoying     Let s say our game needs to have some sort of random thing that annoys the game player when they eat dinner   This could be a HouseFly or a Telemarketer or both -- but how do you allow for both with a single function   And how do you ask each different type of object to  do their annoying thing  in the same way   The key to realize is that both a Telemarketer and HouseFly share a common loosely interpreted behavior even though they are nothing alike in terms of modeling them   So  let s make an interface that both can implement   interface IPest       void BeAnnoying       class HouseFly inherits Insect implements IPest       void FlyAroundYourHead         void LandOnThings          void BeAnnoying             FlyAroundYourHead            LandOnThings             class Telemarketer inherits Person implements IPest       void CallDuringDinner         void ContinueTalkingWhenYouSayNo          void BeAnnoying             CallDuringDinner            ContinueTalkingWhenYouSayNo              We now have two classes that can each be annoying in their own way   And they do not need to derive from the same base class and share common inherent characteristics -- they simply need to satisfy the contract of IPest -- that contract is simple   You just have to BeAnnoying   In this regard  we can model the following   class DiningRoom        DiningRoom Person   diningPeople  IPest   pests               void ServeDinner             when diningPeople are eating           foreach pest in pests         pest BeAnnoying              Here we have a dining room that accepts a number of diners and a number of pests -- note the use of the interface   This means that in our little world  a member of the pests array could actually be a Telemarketer object or a HouseFly object   The ServeDinner method is called when dinner is served and our people in the dining room are supposed to eat   In our little game  that s when our pests do their work -- each pest is instructed to be annoying by way of the IPest interface   In this way  we can easily have both Telemarketers and HouseFlys be annoying in each of their own ways -- we care only that we have something in the DiningRoom object that is a pest  we don t really care what it is and they could have nothing in common with other     This very contrived pseudo-code example  that dragged on a lot longer than I anticipated  is simply meant to illustrate the kind of thing that finally turned the light on for me in terms of when we might use an interface   I apologize in advance for the silliness of the example  but hope that it helps in your understanding   And  to be sure  the other posted answers you ve received here really cover the gamut of the use of interfaces today in design patterns and development methodologies

User · Answer

Imagine you have a product called  Zebra  that can be extended by plugins  It finds the plugins by searching for DLLs in some directory  It loads all those DLLs and uses reflection to find any classes that implement IZebraPlugin  and then calls the methods of that interface to communicate with the plugins    This makes it completely independent of any specific plugin class - it doesn t care what the classes are  It only cares that they fulfill the interface specification    Interfaces are a way of defining points of extensibility like this  Code that talks to an interface is more loosely coupled - in fact it is not coupled at all to any other specific code  It can inter-operate with plugins written years later by people who have never met the original developer   You could instead use a base class with virtual functions - all plugins would be derived from the base class  But this is much more limiting because a class can only have one base class  whereas it can implement any number of interfaces

User · Answer

Q  -      quot Could you use any class that implements an interface  quot  A  - Yes  Q  -      quot When would you need to do that  quot  A  - Each time you need a class es  that implements interface s    Note  We couldn t instantiate an interface not implemented by a class - True   Why  Because the interface has only method prototypes  not definitions  just functions names  not their logic    AnIntf anInst   new Aclass       we could do this only if Aclass implements AnIntf     anInst will have Aclass reference    Note  Now we could understand what happened if Bclass and Cclass implemented same Dintf  Dintf bInst   new Bclass         now we could call all Dintf functions implemented  defined  in Bclass   Dintf cInst   new Cclass         now we could call all Dintf functions implemented  defined  in Cclass   What we have  Same interface prototypes  functions names in interface   and call different implementations  Bibliography  Prototypes - wikipedia

User · Answer

It sounds like you understand how interfaces work but are unsure of when to use them and what advantages they offer  Here are a few examples of when an interface would make sense      if I want to add search capabilities to my application and support multiple search    engines such as Google  Yahoo  Live  etc   interface ISearchProvider       string Search string keywords       then I could create GoogleSearchProvider  YahooSearchProvider  LiveSearchProvider  etc      if I want to support multiple downloads using different protocols    HTTP  HTTPS  FTP  FTPS  etc  interface IUrlDownload       void Download string url        how about an image loader for different kinds of images JPG  GIF  PNG  etc  interface IImageLoader       Bitmap LoadImage string filename      then create JpegImageLoader  GifImageLoader  PngImageLoader  etc   Most add-ins and plugin systems work off interfaces   Another popular use is for the Repository pattern  Say I want to load a list of zip codes from different sources  interface IZipCodeRepository       IList lt ZipCode gt  GetZipCodes string state       then I could create an XMLZipCodeRepository  SQLZipCodeRepository  CSVZipCodeRepository  etc  For my web applications  I often create XML repositories early on so I can get something up and running before the SQL Database is ready  Once the database is ready I write an SQLRepository to replace the XML version  The rest of my code remains unchanged since it runs solely off of interfaces   Methods can accept interfaces such as   PrintZipCodes IZipCodeRepository zipCodeRepository  string state        foreach  ZipCode zipCode in zipCodeRepository GetZipCodes state                 Console WriteLine zipCode ToString

User · Answer

Imagine you have a product called  Zebra  that can be extended by plugins  It finds the plugins by searching for DLLs in some directory  It loads all those DLLs and uses reflection to find any classes that implement IZebraPlugin  and then calls the methods of that interface to communicate with the plugins    This makes it completely independent of any specific plugin class - it doesn t care what the classes are  It only cares that they fulfill the interface specification    Interfaces are a way of defining points of extensibility like this  Code that talks to an interface is more loosely coupled - in fact it is not coupled at all to any other specific code  It can inter-operate with plugins written years later by people who have never met the original developer   You could instead use a base class with virtual functions - all plugins would be derived from the base class  But this is much more limiting because a class can only have one base class  whereas it can implement any number of interfaces

User · Answer

If you program in Java  JDBC is a good example   JDBC defines a set of interfaces but says nothing about the implementation   Your applications can be written against this set of interfaces   In theory  you pick some JDBC driver and your application would just work   If you discover there s a faster or  better  or cheaper JDBC driver or for whatever reason  you can again in theory re-configure your property file  and without having to make any change in your application  your application would still work

User · Answer

In addition to the already selected answer  and the various informative posts here   I would highly recommend grabbing a copy of Head First Design Patterns   It is a very easy read and will answer your question directly  explain why it is important  and show you many programming patterns you can use to make use of that principle  and others

User · Answer

Let s start out with some definitions first   Interface n  The set of all signatures defined by an object s operations is called the interface to the object  Type n  A particular interface  A simple example of an interface as defined above would be all the PDO object methods such as query    commit    close   etc   as a whole  not separately  These methods  i e  its interface define the complete set of messages  requests that can be sent to the object   A type as defined above is a particular interface  I will use the made-up shape interface to demonstrate  draw    getArea    getPerimeter   etc    If an object is of the Database type we mean that it accepts messages requests of the database interface  query    commit   etc   Objects can be of many types  You can have a database object be of the shape type as long as it implements its interface  in which case this would be sub-typing   Many objects can be of many different interfaces types and implement that interface differently  This allows us to substitute objects  letting us choose which one to use  Also known as polymorphism   The client will only be aware of the interface and not the implementation    So in essence programming to an interface would involve making some type of abstract class such as Shape with the interface only specified i e  draw    getCoordinates    getArea   etc   And then have different concrete classes implement those interfaces such as a Circle class  Square class  Triangle class  Hence program to an interface not an implementation

User · Answer

Program to interface  means don t provide hard code right the way  meaning your code should be extended without breaking the previous functionality  Just extensions  not editing the previous code

User · Answer

Programming to Interfaces is awesome  it promotes loose coupling  As  lassevk mentioned  Inversion of Control is a great use of this   In addition  look into SOLID principals  here is a video series  It goes through a hard coded  strongly coupled example  then looks at interfaces  finally progressing to a IoC DI tool  NInject

User · Answer

In Java these concrete classes all implement the CharSequence interface      CharBuffer  String  StringBuffer  StringBuilder   These concrete classes do not have a common parent class other than Object  so there is nothing that relates them  other than the fact they each have something to do with arrays of characters  representing such  or manipulating such  For instance  the characters of String cannot be changed once a String object is instantiated  whereas the characters of StringBuffer or StringBuilder can be edited   Yet each one of these classes is capable of suitably implementing the CharSequence interface methods   char charAt int index  int length   CharSequence subSequence int start  int end  String toString     In some cases  Java class library classes that used to accept String have been revised to now accept the CharSequence interface  So if you have an instance of StringBuilder  instead of extracting a String object  which means instantiating a new object instance   it can instead just pass the StringBuilder itself as it implements the CharSequence interface   The Appendable interface that some classes implement has much the same kind of benefit for any situation where characters can be appended to an instance of the underlying concrete class object instance  All of these concrete classes implement the Appendable interface      BufferedWriter  CharArrayWriter  CharBuffer  FileWriter  FilterWriter  LogStream  OutputStreamWriter  PipedWriter  PrintStream  PrintWriter  StringBuffer  StringBuilder  StringWriter  Writer

User · Answer

I am a late comer to this question  but I want to mention here that the line  Program to an interface  not an implementation  had some good discussion in the GoF  Gang of Four  Design Patterns book   It stated  on p  18      Program to an interface  not an implementation      Don t declare variables to be instances of particular concrete classes  Instead  commit only to an interface defined by an abstract class  You will find this to be a common theme of the design patterns in this book    and above that  it began with      There are two benefits to manipulating objects solely in terms of the interface defined by abstract classes          Clients remain unaware of the specific types of objects they use  as long as the objects adhere to the interface that clients expect    Clients remain unaware of the classes that implement these objects  Clients only know about the abstract class es  defining the interface       So in other words  don t write it your classes so that it has a quack   method for ducks  and then a bark   method for dogs  because they are too specific for a particular implementation of a class  or subclass    Instead  write the method using names that are general enough to be used in the base class  such as giveSound   or move    so that they can be used for ducks  dogs  or even cars  and then the client of your classes can just say  giveSound   rather than thinking about whether to use quack   or bark   or even determine the type before issuing the correct message to be sent to the object

User · Answer

Code to the Interface Not the Implementation has NOTHING to do with Java  nor its Interface construct    This concept was brought to prominence in the Patterns   Gang of Four books but was most probably around well before that  The concept certainly existed well before Java ever existed    The Java Interface construct was created to aid in this idea  among other things   and people have become too focused on the construct as the centre of the meaning rather than the original intent  However  it is the reason we have public and private methods and attributes in Java  C    C   etc   It means just interact with an object or system s public interface  Don t worry or even anticipate how it does what it does internally  Don t worry about how it is implemented  In object-oriented code  it is why we have public vs  private methods attributes  We are intended to use the public methods because the private methods are there only for use internally  within the class  They make up the implementation of the class and can be changed as required without changing the public interface  Assume that regarding functionality  a method on a class will perform the same operation with the same expected result every time you call it with the same parameters  It allows the author to change how the class works  its implementation  without breaking how people interact with it   And you can program to the interface  not the implementation without ever using an Interface construct  You can program to the interface not the implementation in C    which does not have an Interface construct  You can integrate two massive enterprise systems much more robustly as long as they interact through public interfaces  contracts  rather than calling methods on objects internal to the systems  The interfaces are expected to always react the same expected way given the same input parameters  if implemented to the interface and not the implementation  The concept works in many places   Shake the thought that Java Interfaces have anything what-so-ever to do with the concept of  Program to the Interface  Not the Implementation   They can help apply the concept  but they are not the concept

User · Answer

Programming to Interfaces is awesome  it promotes loose coupling  As  lassevk mentioned  Inversion of Control is a great use of this   In addition  look into SOLID principals  here is a video series  It goes through a hard coded  strongly coupled example  then looks at interfaces  finally progressing to a IoC DI tool  NInject

[language-agnostic] What does it mean to "program to an interface"?

Examples related to language-agnostic

Examples related to oop

Examples related to interface