Why use an abstract class rather than an interface?

Question

For example, a real estate builder is building an apartment with many apartments. All rooms in the apartments have the same design, except for the bedroom. The design of the bedroom remains for the people who will own the apartments; beds Rooms can be of different designs for different apartments.

I can achieve this with the abstract class, as shown below:

 public abstract class Flat { //some properties public void livingRoom(){ //some code } public void kitchen(){ //some code } public abstract void bedRoom(); } } 

The implementation class will be as follows:

 public class Flat101 extends Flat { public void bedRoom() { System.out.println("This flat has a customized bedroom"); } } 

Alternatively, I can use interface instead of the abstract class to achieve the same goal as in the following:

 class Flat { public void livingRoom(){ System.out.println("This flat has a living room"); } public void kitchen(){ System.out.println("This flat has a kitchen"); } } interface BedRoomInterface { public abstract void bedRoom(); } public class Flat101 extends Flat implements BedRoomInterface { public void bedRoom() { System.out.println("This flat has a customized bedroom"); } } 

Now the question is: why choose interface (or), why should I use the abstract class?

Answer 1

It depends on your intention or use. But in general, you should use an interface over abstract classes (clause 18 in Bloch efficient Java). Abstract classes are more fragile because someone can modify an abstract class by changing the behavior of other classes that extend from it (this is a common operator).

It is more flexible to work with interfaces, because if you have BedroomInterface and LivingRoomInterface, then you can have a FlatInterface that implements both interfaces, then the Flat101 implementation class implements FlatInterface (instead of spreading from Flat and then implementing the interface). This seems clearer, and later you can have an ExecutiveFlatInterface, which not only has a bedroom and living room, but also guesses the room, after which Flat102 can implement it.

Option 2 is for Flat101 to extend from Flat, then Flat implements BedroomInterface and LivingRoomInterface. It really depends on what you want to do and which methods are probably necessary.

Answer 2

If you are developing an API that will be widely used, you should use both: an interface for expressing a contract that must be implemented through the implementation of classes, and an abstract class that partially implements this interface and thus allows code reuse.

As an example, consider the Java List: methods in the Collections structure (for example, Collections.sort ()) are written in terms of the List interface, which is partially implemented by the AbstractList class, which, in turn, expands to specific LinkedList and ArrayList implementations. LinkedList and ArrayList reuse the code from AbstractList, but this does not stop anyone from writing their own completely separate implementation of List, and then sorting it with Collections.sort ().

However, in many cases this approach may be excessive. If the type hierarchy you are building is used only in a relatively small area, you can simply use abstract classes in general. If you later decide that you want an interface later, this is a pretty painless refactoring task to make a difference.

Abstract classes have several advantages:

• they allow you to specify abstract methods with package / security modifiers
• they facilitate code reuse
• using abstract methods and final methods of the superclass, they allow you to limit the way your class is subclassed, which can be useful in a variety of circumstances (see also template template)
• which refers to classes is generally easier to execute in the IDE (clicking on an "open declaration" on an abstract type of a class type is usually more useful than on an interface type parameter)

Answer 3

If you have a class that provides some functions necessary for derived classes, but each derived class additionally requires a different implementation of other functions, then the abstract class provides a means to determine the overall implementation, leaving the required behavior for the derived classes that must be defined for each derived class.

Answer 4

I consider this a generalization; An abstract class is most useful if the property and behavior of the class are common to the package or module. A good example is a drum brake; since all drum brakes work the same, holding the brakes inside the wheel drum, so this behavior can be inherited in all classes of cars that use drum brakes.

For the interface; it is more like a specification or contract that forces you to realize your speciation. Let's take an example of a building model that has all the speciation, such as doors, a window, an elevator ..... But while you embed the model in the actual building, you need to keep the window, but the internal behavior is determined (because the widow could be a simple widow or slider, color and material ...)

Hope this helps!

Answer 5

I feel when we need to implement some common functions and some abstract functions for several classes, then we should use an abstract class. If we see the Flat example, where we have a common design and some kind of custom design, in this case it is better to use abstract, and then use the interface again to implement the user function, and using abstract as a derived class does not create an additional instance as a normal derived class .

Answer 6

You cannot extend multiple classes, but you can implement more than one interface

If you often need to change your design, then an abstract class is better, because any change occurs in an abstract class, and the need for a force implementation in a subclass is not required. But if there are any changes in the interface, you must implement the implementation class.