Abstract classes and best practice interfaces in java

So, you have an interface and an abstract class that implements a subset of the methods in the interface. You also have some classes that inherit from an abstract class and provide implementations of methods that an abstract class does not.

So what is the best thing here? I am talking about issues such as:

1) Should an abstract class implement an interface or its child classes? Do each class have to? It seems to me that only an abstract class should. Of course, all classes could implement the interface, but this seems superfluous because the children of the abstract will "inherit" the interface, because they extend the abstract class.

2) Given that an abstract class implements parts of an interface, should it also declare abstract methods for methods that it does not implement? It seems to me that this is correct, but in some ways it seems unnecessary, because abstract children will have to implement these methods for compilation.

So what are your arguments for best practice? The question comes down to the following: we have an interface that determines what we want from some classes, we have a subset of the methods in the interface that define general behavior, and we have several different ways to define non-general behavior. What is the best way to do this?

+4
source share
5 answers

The principle that should help you here is id DRY: do not repeat yourself ( http://en.wikipedia.org/wiki/Don%27t_repeat_yourself ).

In this context, DRY means that you should not do unnecessary work.

So, for your first question, an abstract class must implement an interface because it saves you from repeating the "implements X" sentence in each particular class.

As for the second question, it makes no sense to repeat the methods of the interface in an abstract class that implements it. This is redundant work. Moreover, when the interface develops / changes, you will need to change the methods (abstract) in the abstract class, which is a headache. At some point, you will miss updating some methods, and a particular class will need to implement them in vain.

+8
source

An abstract class must implement an interface and provide concrete implementations of common member functions. IIRC does not need to declare abstract methods for elements that it does not implement, since they are assumed to be subclasses necessary for implementation.

+2
source

The most flexible way of programming for this:

  • Provide an interface
  • Provide an abstract class that implements an interface
  • Provide specific classes that either extend from an abstract class or extend from another class and implement an interface
  • Alway (if you cannot) declare variables / parameters / constants as an interface, not an abstract class or concrete classes

It makes no sense for concrete classes to implement the interface (later). It makes no sense in an abstract class to repeat abstract methods from an interface.

By doing # 4, you guarantee that all classes that implement the interface can be used - if you used an abstract class, classes that implement the interface but do not extend the abstract class can not be used instead.

(later part)

One argument for an abstract class and specific classes to implement an interface is that if you subsequently change a specific class so that you no longer extend the abstract class, then you might forget to also implement an interface, which in some may break the code without compiler complaints. I do not know how I feel about this argument.

+2
source

Interface methods are implicitly abstract, so if an abstract class implements an interface, there is no need to satisfy an interface contract in an abstract class. The abstract interface is technically legal, but also redundant. It is great for an abstract class to implement an interface if all subclasses otherwise implement the interface, but the abstract class should not contain implemented methods.

Interface methods are implementation-specific (unique to the implementation class), while abstract states and behavior must be shared or shared with implementations. It would be an oxymoron to implement interface methods as common functionality.

The key question is: what do you plan to do with interface implementations? If the base interface is not used for anything other than defining an additional contract, I would simply add abstract methods to the abstract class, otherwise the interface will be redundant. If you find a use case in which you need access to interface methods, but not necessarily general functionality, then perhaps the interface is worth it.

+1
source

Do you have more interface implementations than an abstract class or subclasses? Does your design need an interface? Otherwise, the interface will not give anything for your design, and I suggest you just get rid of it.

When it comes to your explicit questions, an abstract class should implement an interface. Classes extending an abstract class should not.

You should not over-declare abstract methods in an abstract class that is already in the interface.

0
source

All Articles