So continuing on from the preceding article Interfaces – The quest for reuse. [Part 1 – Concrete class] that explored ways to achieve code re-use by making use of a concrete class, we will now have a look at achieving this by making use of the abstract class.
Abstract class:
What is an abstract class? Firstly, abstract classes cannot be instantiated, as opposed to their concrete class counterparts, which can. By definition it is a class that contains one or more abstract members. You might be asking: what is abstract member? A more simplified way of putting it, would be to state that an abstract member is a class member that is declared, but not implemented. The class that inherits from the abstract class MUST implement these abstract members. Let’s have a look at the Abstract class variant using the same Polygon example.
Note the similarities:
- Same constructor.
- Same member fields.
Note the differences though:
- Note that the function GetArea() contains NO method body and is only a declaration!
- Note that the function GetArea() is marked with the abstract keyword, making it an abstract member.
- Because the class contains a member GetArea() that contains the abstract keyword, we are forced by the compiler to also mark the class AbstractRegularPolygon with the abstract keyword.
So what does it practically mean to have an abstract class? It means that you are not allowed to create an instance of this class as it contains member(s) that are not implemented. The only purpose an abstract class serves is to act as a base class for a child class – where the child class then implements / overrides these members. Let’s have a look at a scenario where this is implemented.
On the surface this class has similarities to the Square class example. Here it obviously inherits from the AbstractRegularPolygon class and the GetArea() method is also overridden, but here with the (tad more complex) calculation of the area of a Triangle.
When we run the code, we get similar results as with the square example.
So what is different here? Well that becomes clear when we comment out the override of GetArea() in the Triangle class and attempt to compile our code. Let’s have a go at it.
As you can see we get a build failure! ‘Polygons.Library.Triangle’ does not implement inherited abstract member ‘Polygons.Library.AbstractRegularPolygon.GetArea()’
Why? The reason for this is that the compiler forces us (and rightly so) to provide an implementation for the abstract member GetArea(). This is done during compile time and the compiler checks that the overriding of the GetArea() function was indeed done in the child class!
For the purpose of this explanation this is the main difference between the concrete and abstract class.
To summarize the re-use abilities of the abstract class:
Re-use is surely possible, more so, one gets the idea that the class was designed with this specific purpose in mind! That is indeed true seeing that you can only inherit from it. The one great advantage you get from using an abstract class is that you get compile time checking on the implementation of abstract members in the child classes. This is a strong plus point.
In the next section we will have a look at achieving code re-use by making use of a Interfaces!
Unravelling Software Development 