• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Programming to Interfaces

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,
I have been hearing that we have to program to interfaces and not to the implementation. My question is what will happen if we program to implementation. In otherwords, why we have to program to interfaces ?

For instance, if class A has a dependency on class B and class B has a method called display() which System.out the string "hello".

In main method of Class A, an instance of Class B (say b) is created and b.display() is called. We get the output "hello". Now i changed the display() method in class B to display "hello world" instead of "hello". I just compiled the class B but not class A. Now when I run the main method it shows "hello world" and not "hello". So my understanding is that Class A not depends on Class B right?. In otherwords, the changes to class B won't affect class A right ? Then what's wrong with programming to implementation ?

I will appreciate if anyone gives proper explanation.

Thanks,
Mohamed
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
With "programming to interfaces" it is meant that, as much as possible, you should declare your variables or parameters as being of the interface type, not an implementation type. So:

instead of

This allows you to change the implementation class if needed; if a LinkedList or TreeSet becomes better, you only need to change it when you initialize or assign to the variable.

Please note that this principle also holds for non-interface classes: declare as broad as possible. So don't declare as SimpleDateFormat but as DateFormat, don't declare as JPanel but as JComponent or better yet Container or Component*. This principle is used to a great extent in Containers themselves - they can except any Component, it doesn't matter of which class.

* Of course if you need methods / fields of a specified subclass (such as JSpinner's getValue() method) there is nothing wrong with declaring it as a JSpinner because it's obvious that you'll never use anything else.
 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Rob, but you can go even further with this concept. With Rob's solution, you still have to change the code on the page to make the switch to a different subclass implementation. While it's true that this forces you not to use the subclass specific methods (which is a good thing), it also is not the best we can do. The next logical progression is factory methods, which puts the generation logic in a centralized method that you call from multiple places. Right now, the best way (if you can manage) is using inversion of control or dependency injection through some container like PICO or Spring. This allows you to encode the type of class generated in an XML configuration. This seems to be the most flexible arrangement currently.
Hope this helps.
 
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
John's reply is probably the next phase of a developers career, where you may be designing, creating, and implementing custom api's, or extending current API's.

For a more general explanation, we like to write chunks of code that are applicable to many different implementations (ie: driving software for many types of cars) - the only we we can programatically do that is to write our API based upon interfaces, and allow our code to execute on specific implementations that adhere to our interfaces.

Imagine interfaces as kind of like an exhaust manifold on a car - one side bolts to an engine (interface), it has some pipes in the middle to transfer the exhaust, and the other side bolts to the exhaust pipe. I can put different types of exhaust pipes on my car if they all can bolt up to my exhaust manifold.

Get it?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let's picture an even simpler situation where we don't create anything.

If you write this method, I can call it with an ArrayList, a LinkedList, a MyNewFangledList, or anything that implements List. The List interface assures you that whatever comes along will have a size() method.

But if you wrote:

I could only call you with ArrayList which might get in the way of future changes on my end.
 
reply
    Bookmark Topic Watch Topic
  • New Topic