• 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

Designing to interfaces?

 
Ranch Hand
Posts: 153
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have just heard about the 'Designing to Interfaces' concept.

I am required to implement this design methodology very soon, but I am not fully sure how it works.

What I learned so far is this:

Example A
-------------

Here, using a ShapeInterface decouples this Main app from any subshape object (Rectangle, Triangle, etc.).
So if I need to add a Shape type object in the future, I don't have to modify the client code because it's been 'coded to the interface'.
I only have to change the actual implementation in the concrete class itself.



Example B
-------------

This code is easy to break because this Main app will be tightly coupled to every future shape object I need (if there comes a Rectangle, I will need to change the code to instantiate a Rectangle etc.).
Also, the implementations are different and so I have to apply the appropriate implementation (Rectangle.draw(), Triangle.draw(), etc.)



I understood this concept. Using an interface so that you won't have the change the code that uses the underlying concrete classes. Ok, understandable. I see the advantage.

Here's the concept that I don't understand:

Example C
-------------

This example illustrates composition instead of inheritance (Object A has an Object B rather than IS-A B).
A can't print directly, it has to delegate to B. Fine, I understand that. What I don't understand is the advantage of this.

Couple of questions:

1) How was it decoupled?
2) Will putting the interface in between A and B decouple their relationship?
3) What if there was no interface between them? Then A would be tightly coupled to B?
4) If B disappears, can I simply replace it with a C class thanks to the interface?

If I don't understand these concepts then I can't move on in my design.



Ok, so that's that. However, I have another big problem:

Say I have a couple of classes that implement a particular interface. Now say that later, there is one method in that interface that I don't need anymore and thus need to delete.
Then it will cause a ripple-effect to the classes that implemented that interface because the implementation won't be correct anymore.

How do I avoid/deal with this?

It's quite a problem..
Any ideas on this?

Thank you,

--
Ryan




 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ryan McClain wrote:Say I have a couple of classes that implement a particular interface. Now say that later, there is one method in that interface that I don't need anymore and thus need to delete.
Then it will cause a ripple-effect to the classes that implemented that interface because the implementation won't be correct anymore.

How do I avoid/deal with this?



That isn't correct. The rule is that for a class to correctly implement an interface, it must provide implementations for all of the methods declared by the interface. (Or if it doesn't, it must be declared "abstract", but let's leave that aside for now because it isn't related to your question.)

You appear to be assuming that for a class to correctly implement an interface, it must not provide implementations for methods not declared by the interface. But this is not correct -- there is no such rule. Now consider your example -- your interface no longer declares the X method, but your classes still contain implementations of that method. This isn't a problem at all, since it doesn't break any rules. So you don't need to deal with it.
 
Ryan McClain
Ranch Hand
Posts: 153
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, in my case it's a problem because I am working with Spring (a dependency injection framework).

I may not use the 'new' keyword anywhere nor may I write methods in classes that are not tied to an Interface.
The problem is that the Interface no longer knows about my custom method, so how will the View tier access it? By Spring.xml perhaps?
It needs the interface method.

View -> MiddleTier.interfaceMethod() -> businessClass.method() -> Hibernate.method -> db_CRUD
??? -> unreachable

As I showed in my example A and B: the code will break if I am no longer coding to interfaces.
Leaving the method out of the interface and coupled to the business class will make it unreachable/invisible for the View tier because the View tier uses the interface to begin with.

 
Paul Clapham
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I expect I'm missing something, but why isn't the answer "Then put that method back into the interface"?
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic