How is abstract class different from concrete class?

Question

I understand WHY we need Abstract Class in Java - to create sub-classes. But the same can be achieved by concrete class. e.g. Class Child extends Parent. Here Parent can very well be abstract & concrete. So why do we have ABSTRACT??

Solution 1

Abstract classes cannot be instantiated directly. Declaring a class as abstract means that you do not want it to be instantiated and that the class can only be inherited. You are imposing a rule in your code.

If you extend your Parent/Child relationship example further to include a Person class then it would make good sense for Person to be abstract. Parent is a concrete idea and so is child. Person is an abstract concept in reality as well as in code.

One benefit is that you explicitly define and protect the idea of the abstract class. When you declare a class as an abstract there's no way that you or anyone else using your code uses it incorrectly by instantiating it. This reasoning is similar to why we specify functions and fields as public, private or protected. If you declare a function or member as private you are in effect protecting it from improper access from client code. Privates are meant to be used within the class and that's it. Abstract classes are meant to be inherited and that's that.

Now, do you have to use abstract classes and define functions and fields as private instead of public? No, you don't. But these concepts are provided to help keep code clean and well-organized. The abstract class is implemented in all object-oriented languages to my knowledge. If you look around you will see that C++, C#, VB.NET etc. all use this concept.

A better, specific example:

In the example above the Shape class should be abstract because it is not useful on its own.

Solution 2

Abstract class means it is abstract not complete. It needs another class to complete it and/or its functionalities. You need to extend the abstract class. It will be useful with Certain class eg. Fruit all fruits have the same property like color. But you can have different properties for different fruits like is it pulpy such as orange or not eg Banana etc.

Solution 3

I know this is an old question but it looks like the poster still had some questions about the benefit of using an abstract class.

If you're the only one who will ever use your code then there really is no benefit. However, if you're writing code for others to use there is a benefit. Let's say for example you've written a caching framework but want to allow clients to create their own caching implementation classes. You also want to keep track of some metrics, like how many caches are open, hypothetically. Your abstract class might look something like this:

public abstract class AbstractCache {
    public final void open() {
        ... // Do something here to log your metrics
        openImpl();
    }

    protected abstract void openImpl() { }
}

On its own the AbstractCache class is useless and you don't want clients to try to instantiate one and use it as a cache, which they would be able to do if the class was concrete. You also want to make sure they can't bypass your metric logging, which they would be able to do if you just provided them a Cache interface.

Solution 4

An abstract class is meant to be used as the base class from which other classes are derived. The derived class is expected to provide implementations for the methods that are not implemented in the base class. A derived class that implements all the missing functionality is called a concrete class

Solution 5

The point of abstraction is not to create sub-classes. It's more about creating Seams in your code. You want code to be test-able and decoupled which lead to the ultimate goal of maintainability. For similar reasons, abstraction also buys us the ability to replace a bit of code without rippling side effects.

View more solutions

Comments

[Polity]

Animal animal = new Animal(); << what animal? in many cases this doesn't make sense, hence abstract classes. You can't create an instance directly. It has to be a subtype like a cat or dog or whatever

[Ashish K Agarwal]

programmatically the same can be achieved if we would have had Animal as a concrete class. I am just trying to understand the rationale behind introducing a concept of ABSTRACT by the java creators.

[Nitin Chhajer]

It limits the redundancy of the code and also increases the effectiveness. Moreover it can impose that certain incomplete functionality of the abstract class be used in the concrete class. Much like combining an interface and class together and you don't have to implement the interface in all your concrete classes.

[Ashish K Agarwal]

but what benefit do we gain by imposing this rule?

[Colin D]

Code reuse. Implement the function in the abstract class and now all subclasses have that method implemented. This is commonly used when implementing interfaces and multiple implementations share the same code for some methods.

[Ashish K Agarwal]

but the point is the same can be achieved by a concrete class. I am trying to understand if there is anything beyond the fact that abstract class is there for classes which are LOGICALLY not concrete or is there something more ?

[Nitin Chhajer]

In that case the answer is no. You can have your entire app (even 100KLOC+) in one class. But we don't, and we make different classes for different entities. Abstract class improves the structure of the program

[Mark Rotteveel]

I think Parent / Child / Person is a bad analogy for explaining abstraction and inheritance: a person is always a child (of two other persons) and it is very common that after a point in time they are also a parent (of some other person(s)).

[Paul Sasik]

@MarkRotteveel: I agree. That's an analogy often taught in CS classes and it does not make a great deal of sense. A better example is shapes IMO. If creating an app that draws shapes it would make perfect sense to create an abstract class Shape. From it you would inherit and create Rectangles, Circles etc. and it would never make sense to instantiate a Shape.