This blog is subject the DISCLAIMER below.

Monday, March 10, 2008

OOP Design Concepts - Abstract Classes

hey all, and specially soli who asked about abstract classes.
In this post we discuss abstract classes, however, it would be better if you read the post titled OOP Design Concepts - Interfaces first.

- What is an abstract class?

Abstract classes are partial classes, in other words, they are classes that needs to be inherited by other classes to be used. The word abstract means that methods inside such class are not completely implemented, an abstract class can mark some methods as abstract, so, the child class needs to implement them according to its behavior. An abstract class works as a generalized type that needs specialization for each subtype.



Well, i hate those complex descriptions, so lets get to the example mentioned previously in OOP Design Concepts - Interfaces. The case was that we had different types of cars and we specified their behavior by an interface named "iMovable", now, lets consider an extension to that design. Suppose that all cars starts using the same way using the same method of ignition, so, it is not relevant for every car to implement the method named "Start" with the same implementation. In this case we will introduce the abstract class named "Car", this class implements the "iMovable" interface and introduces a new method named "Start" and implements it. Now, any new car will extend the abstract car instead of directly implementing "iMovable".

- A closer look.
So, we did not forget that the abstract car implements iMovable, but we did not mention any thing about implementing iMovable's methods?. yes, the methods are still treated the same way, as the classes extending the abstract car are still responsible for providing the actual implemenation of such methods, in our case, it is the single move method. Methods in interfaces are abstract by default, and marking a class as abstract indicates that this class is not yet complete, so it has the option to implement what it wants from the interface, and in our case, we need nothing from the interface to be implemented in the abstract car.
Now, any car extending the abstract car can use the start method directly but it still have to implement how the move method will be implemented.
An abstract class may implement methods declared in an interface, thus, making it an option for subclasses to override those methods or not.

-Why?
The previous modification makes classification perfect, as we said before, it is all about logical thinking, reconsidering the first design that rely only on interfaces, you will find it not logic that every movable object is a car!!, so, abstract classes provides an extra level of specialization, as we can introduce an extra specification level to more subtypes. In our case, we defined a common behavior for cars, if we have planes, we will introduce the plane type the same way we did with cars.

-Coding
lets see an java code segment declaring our example class.

public abstract class Car implements iMovable{

public void start()
{
//code for starting engine
}

//Another method marked abstract for implementation by child classes
public abstract void koko();
}


public class NormalCar extends Car{

//The method declared by the iMovable interface.
public void move()
{
//code for moving...
}

public void koko()
{
//Code for the koko method which does anything.....
}

}


Marking a method as abstract, makes it a must for child classes to implement such a method or the code will not compile, thus forcing the same kind of behavioral description provided by interfaces in the older design.

7 comments:

soli said...

thanks a lot it's really very great job.

Anonymous said...

thank you so much
********************************
::::::::::::::::::::::::::::::
::::::::::::::::::::::::::::::
:::::T:::::::::::::::::::)::::
::::::H::::::::::::::::H::::::
:::::::A::::::U:::::::C:::::::
::::::::N::::O::S::::U::::::::
:::::::::K::Y::::O::M:::::::::
::::::::::::::::::::::::::::::
::::::::::::::::::::::::::::::
********************************

Anonymous said...

These were really nice articles , too bad u stopped

abbas said...

Thanks mate, you have explained really well about interface and abstract class.

Anonymous said...

Still relevant 2 years later. This and the Interface article (and its comments) taken together work really well to explain parts of abstraction that I didn't pick up in my Comp Sci classes.

Thank you for taking the time to write this.

dedeepya said...

v.nice...
but still it ll be glad if u explain how abstract classes nad interface satisfing abstraction principle that is hiding unnecessary methods to make user friendly application.and from thre how overloading and overriding came.

Anonymous said...

Aneesh Thankachan

Thanks, topic is dealt with good clarity........!!!!