aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Programming to interfaces or abstract classes? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Programming to interfaces or abstract classes?" Watch "Programming to interfaces or abstract classes?" New topic
Author

Programming to interfaces or abstract classes?

Sanjeev Arya
Ranch Hand

Joined: Feb 13, 2001
Posts: 58
Hi,
OOP experts, including the GoF, often recommend "programming to an interface" for benefits of decoupling and polymorphism. That makes sense. Does that mean it may be useful to refactor the design for some patterns to include an interface on top of abstract classes?
It seems Abstract classes may be useful in patterns such as Template Method, or Singleton (for subclasses). Since C++ does not have explicit interfaces, the GoF often use Abstract classes in their class diagrams for patterns where we'd use interfaces in Java. However, for these 2 patterns at least we would invariably end up having an abstract class in Java too. Hence my question, shall we further include an interface on top of the hierarchy? Can it be an overkill?
Maybe fellow patterners in this forum will throw some light... probably with reference to Singleton or Template Method patterns.
Thanks
Sanjeev
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Sanjeev Arya:
Hi,
OOP experts, including the GoF, often recommend "programming to an interface" for benefits of decoupling and polymorphism. That makes sense. Does that mean it may be useful to refactor the design for some patterns to include an interface on top of abstract classes?
It seems Abstract classes may be useful in patterns such as Template Method, or Singleton (for subclasses). Since C++ does not have explicit interfaces, the GoF often use Abstract classes in their class diagrams for patterns where we'd use interfaces in Java. However, for these 2 patterns at least we would invariably end up having an abstract class in Java too. Hence my question, shall we further include an interface on top of the hierarchy? Can it be an overkill?
Maybe fellow patterners in this forum will throw some light... probably with reference to Singleton or Template Method patterns.
Thanks
Sanjeev


Why dod you need an abstract class for Singleton? I'm not usre I get it.
For a pattern like Singleton, I don't see the need for a new interface. Interfaces are used when multiple, distinct classes (i.e. not with the same lineage) all need to exhibit the same behavior. With the Singleton, there will generally be only one object of that class. It's unlikely that you'll have other classes with similar behaviors, so an extra interface is unnecessary.
However, that is not to say there may not be other patterns of of which your Singleton is a part, which would require an interface. But then the interface would be used for the other pattern and not for the Singleton pattern.
--Mark
hershey@vaultus.com
Sanjeev Arya
Ranch Hand

Joined: Feb 13, 2001
Posts: 58
Originally posted by Mark Herschberg:

Why dod you need an abstract class for Singleton? I'm not usre I get it.
For a pattern like Singleton, I don't see the need for a new interface. Interfaces are used when multiple, distinct classes (i.e. not with the same lineage) all need to exhibit the same behavior. With the Singleton, there will generally be only one object of that class. It's unlikely that you'll have other classes with similar behaviors, so an extra interface is unnecessary.
However, that is not to say there may not be other patterns of of which your Singleton is a part, which would require an interface. But then the interface would be used for the other pattern and not for the Singleton pattern.
--Mark
hershey@vaultus.com


Suppose there is an Amphibian ship (abstract class) which does some common work for amphibian ships, say maintain a log etc. It can become a Land vehicle or a Water vehicle (concrete implementations). Lets say at any given time the Captain needs only one instance of the amphibian? How do we do that?
We could make both Land vehicle and Water vehicle singletons but that wouldn't stop both from existing at the same time, right? We want only one and the same amphibian at any given time.
Sorry this is hypothetical but I thought of this when seeing the GoF mention Singleton in case of subclasses. Not much detail there about this.
Sanjeev
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
This sounds like a combination of the Factory and Singleton patterns.


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
I believe, when we talk in terms of abstract classes Singleton Pattern makes little sense.You would need to implement Singleton pattern for every single class for which you require only one global instance.If you have 100 subclasses, and you want single instance of every single subclass you would need to have all your subclasses based on Singleton Pattern.
Using abstract classes is useful if you know about the possible implementation for your class.Larman gives an example on Payment as an abstract class, since he is sure on all possible modes of Payment,viz., cash, credit and card.Each mode of payment would be a subclass (concrete implementation) of the abstract class.Note that Payment instance here is not meaningful, hence we make it abstract, and also donot apply Singleton Pattern to it(In any case, Java does not permit instantiating an abstract class )
As regards "Programming to an Interface", it allows us to change/plug an implementation without affecting the client.Any implementation would only inherit the responsibilities not its capabilities of the interface.
So in the above example, if you consider to refactor your code, and make an interface like PaymentInterface and an abstract Payment class which inherits from this interface, the interface is saying "Please implement the responsibility".But, what does the Payment say "Sorry, I do not know that as of now, will implement later!!".This does not sound good at all!!
Also note that you are trying to doubt on the credibility of the original abstract class - After all you made the abstract class because you knew all the modes of Payment.By keeping interface at the top of the heirachy, you will be contradicting by saying, you may later on identify some other mode of Payment.Also this mode of Payment could be another abstract class or concrete class for PaymentInterface, which may or may not be a sub class of your original abstract Payment class.Do your really want this to happen?
I think, one should decide on this based on the need.If you feel the implementation is to be provided by different parties, an interface is better.If you could forsee a limited number of concrete implementation then abstract class is better.
Hope this helps,
Sandeep


<b>Sandeep</b> <br /> <br /><b>Sun Certified Programmer for Java 2 Platform</b><br /> <br /><b>Oracle Certified Solution Developer - JDeveloper</b><br /><b>-- Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java </b><br /><b>-- Object-Oriented Analysis and Design with UML</b><br /> <br /><b>Oracle Certified Enterprise Developer - Oracle Internet Platform</b><br /><b>-- Enterprise Connectivity with J2EE </b><br /><b>-- Enterprise Development on the Oracle Internet Platform </b>
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Programming to interfaces or abstract classes?