aspose file tools*
The moose likes Beginning Java and the fly likes Designing to interfaces? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Designing to interfaces?" Watch "Designing to interfaces?" New topic
Author

Designing to interfaces?

Ryan McClain
Ranch Hand

Joined: Nov 27, 2010
Posts: 110
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




Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18991
    
    8

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

Joined: Nov 27, 2010
Posts: 110
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
Bartender

Joined: Oct 14, 2005
Posts: 18991
    
    8

I expect I'm missing something, but why isn't the answer "Then put that method back into the interface"?
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Designing to interfaces?