aspose file tools*
The moose likes Beginning Java and the fly likes Design decision: Interface+Abstract+Concrete class vs. Interface+Concrete class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Design decision: Interface+Abstract+Concrete class vs. Interface+Concrete class" Watch "Design decision: Interface+Abstract+Concrete class vs. Interface+Concrete class" New topic
Author

Design decision: Interface+Abstract+Concrete class vs. Interface+Concrete class

Peter Kovac
Ranch Hand

Joined: Aug 08, 2010
Posts: 42
Hi,

The other day I did an implementation of a feature like:


I have an interface, an abstract class providing default implementations and another class (DoStuff) that does nothing just makes the abstract class accessible.
During code review it was suggested that as DoStuff does nothing but exposing the abstract class and we do not have other implementations of AbstractDoStuff we should only have an interface and an implementation w/o the abstract class in the middle.. Should the need arise for another implementation we should create the abstract class but not until then, so we have less code to tend..

My question: is that a correct suggestion on design?

Thanks,




Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14347
    
  22

I would say yes - why make an abstract class when it's not necessary? That only adds code, making your program longer and more complex for no benefit.

Sometimes it is beneficial to provide an abstract class, especially if you want a default implementation for some of the methods of the interface. If you then make multiple concrete classes that have to implement the interface, you can make those extend the abstract class, so that they inherit the implementation of the methods from the abstract class.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Peter Kovac
Ranch Hand

Joined: Aug 08, 2010
Posts: 42
Jesper de Jong wrote:I would say yes - why make an abstract class when it's not necessary? That only adds code, making your program longer and more complex for no benefit.
Sometimes it is beneficial to provide an abstract class, especially if you want a default implementation for some of the methods of the interface. If you then make multiple concrete classes that have to implement the interface, you can make those extend the abstract class, so that they inherit the implementation of the methods from the abstract class.


Thanks.. But if we have only an interface and a implementation class we can just start by having a class and then extract an interface as the need arise.
The issue I see here that if we have an interface then we can refer the class by the interface and not the concrete class, but if the class is not to be extended for the foreseeable future then the interface might just add another level of maintenance..

Also if we have an abstract class we can start separating concerns over a general abstract class and a specialized implementation very early that can be more expensive if we need to re-factor the structure later.

Do you have any experience how much burden the one abstract class-one implementing class scheme add to the maintenance for a longer term in an enterprise code base?
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14347
    
  22

Peter Kovac wrote:Do you have any experience how much burden the one abstract class-one implementing class scheme add to the maintenance for a longer term in an enterprise code base?

It's hard to say in general how much of a burden it is (and how would you measure that - what are the units for "amount of burden"?).

But as I already said: why make things more complicated than necessary? Start simple. When, someday, you find that you do need an abstract class in between your interface and concrete class, you can just refactor your code (which an IDE will help you with). Programmers often want to make things more flexible, because they think that's better and someday they're going to need the flexibility. But making it more flexible often also makes the code more complex, which is going to make it harder to understand for people who have to maintain it later. See the YAGNI principle.
Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

Interface is for generalization.
Peter Kovac wrote:
Do you have any experience how much burden the one abstract class-one implementing class scheme add to the maintenance for a longer term in an enterprise code base?

one abstract class-one implementing class? then why cant you make it one.

Personally, I prefer AbstractInterface.
Peter Kovac
Ranch Hand

Joined: Aug 08, 2010
Posts: 42
Thank you guys.. what's the book you recommend on this topic ?
Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

*Head First Design Pattern
*Effective Java
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5018
    
    8

I agree with the code review results for the same reasons Jesper gave. This is "agile design" thinking or perhaps more appropriately, "lean design" thinking. If you're looking for books, consider "Clean Code" and "Agile Software Development: Principles, Patterns, and Practices", both written by Robert Martin. The additional complexity that's not used is considered as "technical debt" -- it's waste because you put in more effort to write something that you think might be useful in the future although it's not actually being used now. It's software "inventory". Since developers are not normally psychics, this kind of "future proofing" does not always pay off. In fact, the Pareto Principle will usually apply: bets like this will only pay off 20% of the time (80% of future proofing code will only pay off 20% of the time)


Junilu - [How to Ask Questions] [How to Answer Questions]
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Design decision: Interface+Abstract+Concrete class vs. Interface+Concrete class