• 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 or abstract classes?

 
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This sounds like a combination of the Factory and Singleton patterns.
 
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic