What code should be included in an abstract class?

Question

I am troubled lately about the use of abstract classes.

Sometimes an abstract class is created in advance and work as a template of how the derived classes would work. That means, more or less, that they provide some high level functionality but leaves out certain details to be implemented by derived classes. The abstract class defines the need for these details by putting in place some abstract methods. In such cases, an abstract class works like a blueprint, a high level description of the functionality or whatever you wanna call it. It cannot be used on its own, but must be specialized to define the details that have been left out of the high level implementation.

Some other times, it happen that the abstract class is created after the creation of some "derived" classes (since the parent/abstract class is not there they have not been derived, yet, but you know what I mean). In these cases, the abstract class is usually used as a place where you can put any kind of common code that current derived classes contain.

Having made the above observations, I am wondering which of these two cases should be the rule. Should any kind of details be bubbled up to the abstract class just because they currently happen to be common in all the derived classes? Should common code that is not part of a high-level functionality be there ?

Should code that may have no meaning for the abstract class itself be there just because it happens to be common for the derived classes?

Let me give an example: Abstract class A has a method a() and an abstract method aq(). The method aq(), in both derived classes AB and AC, uses a method b(). Should b() moved to A ? If yes, then in case someone looks only at A (let's pretend AB and AC are not there), the existence of b() would make no much sense! Is this a bad thing? Should someone be able to have a look in an abstract class and understand what is going on without visiting the derived classes?

To be honest, at the moment of asking this, I tend to believe that writing an abstract class that makes sense without having to look in the derived classes it is a matter of clean code and clean architecture. Ι don't really like the idea of an abstract class that acts like a dump for any kind of code happens to be common in all derived classes.

What do you think/practice ?

Answer 1

It seems to me you are missing the point of object orientation, both logically and technically. You describe two scenarios: grouping common behavior of types in a base class and polymorphism. These are both legitimate applications of an abstract class. But whether you should make the class abstract or not depends on your analytical model, not the technical possibilities.

You should recognize a type that has no incarnations in the real world, yet lays the groundwork for specific types that do exist. Example: an animal. There is no such thing as an animal. It is always a dog or a cat or whatever but there is no real animal. Yet Animal frames them all.

Then you speak of levels. Levels are not part of the deal when it comes to inheritance. Nor is recognizing common data or common behavior, that is a technical approach which will likely not help. You should recognize a stereotype and then insert the base class. If there is no such stereotype, you may be better of with a couple of interfaces that are implemented by multiple classes.

The name of your abstract class together with its members should make sense. It must be independent of any derived class, both technically and logically. Like Animal could have an abstract method Eat (which would be polymorphic) and boolean abstract properties IsPet and IsLifestock, that makes sense without knowing about cats or dogs or pigs. Any dependency (technical or logical) should go one way only: from descendant to base. Base classes themselves should have no knowledge of descending classes either.

Answer 2

Let me give an example: Abstract class A has a method a() and an abstract method aq(). The method aq(), in both derived classes AB and AC, uses a method b(). Should b() moved to A ? If yes, then in case someone looks only at A (let's pretend AB and AC are not there), the existence of b() would make no much sense! Is this a bad thing? Should someone be able to have a look in an abstract class and understand what is going on without visiting the derived classes?

What your asking is where to place b(), and, in some other sense a question is whether A is the best choice as the immediate super class for AB and AC.

It seems there are three choices:

1. leave b() in both AB and AC
2. create an intermediate class ABAC-Parent that inherits from A and that introduces b(), and is then used as the immediate super class for AB and AC
3. put b() in A (not knowing whether another future class AD will want b() or not)

---

1. suffers from not being DRY.
2. suffers from YAGNI.
3. so, that leaves this one.

Until another class AD that doesn't want b() presents itself, (3) seems like the right choice.

At such time as an AD presents, then we can refactor to the approach in (2) — after all it is software!

Answer 3

An abstract class is not meant to be the dumping ground for various functions or data that are thrown in to the abstract class because it is convenient.

The one rule of thumb that seems to provide the most reliable and extendable object oriented approach is "Prefer composition over inheritance." An abstract class is probably best thought of as an interface specification which doesn't contain any code.

If you have some method that is a kind of library method that goes along with the abstract class, a method that is the most likely means of expressing some functionality or behavior that classes derived from an abstract class typically need then it makes sense to create a class in between the abstract class and other classes where this method is available. This new class provides a particular instantiation of the abstract class defining a particular implementation alternative or path by providing this method.

The idea of an abstract class is to have an abstract model of what the derived classes which actually implement the abstract class are supposed to provide so far as service or behavior. Inheritance is easy to over use and so many times the most useful classes are composed of various classes using a mixin pattern.

However there are always the change questions, what is going to change and how will it change and why will it change.

Inheritance can lead to brittle and fragile bodies of source (see also Inheritance: just stop using it already!).

The fragile base class problem is a fundamental architectural problem of object-oriented programming systems where base classes (superclasses) are considered "fragile" because seemingly safe modifications to a base class, when inherited by the derived classes, may cause the derived classes to malfunction. The programmer cannot determine whether a base class change is safe simply by examining in isolation the methods of the base class.

Answer 4

Your question suggests an either or approach to abstract classes. But I think that you should consider them as just another tool in your toolbox. And then the question becomes: For which jobs/problems are abstract classes the right tool?

One excellent use case is to implement the template method pattern. You put all invariant logic in the abstract class and the variant logic in its subclasses. Note, that the shared logic in itself is incomplete and non-functional. Most of the time it is about implementing an algorithm, where several steps are always the same, but at least one step varies. Put this one step as an abstract method that is called from one of the functions inside the abstract class.

Sometimes an abstract class is created in advance and work as a template of how the derived classes would work. That means, more or less, that they provide some high level functionality but leaves out certain details to be implemented by derived classes. The abstract class defines the need for these details by putting in place some abstract methods. In such cases, an abstract class works like a blueprint, a high level description of the functionality or whatever you wanna call it. It cannot be used on its own, but must be specialized to define the details that have been left out of the high level implementation.

I think your first example is essentially a description of the template method pattern (correct me if I'm wrong), so I would consider this as a perfectly valid use case of abstract classes.

Some other times, it happen that the abstract class is created after the creation of some "derived" classes (since the parent/abstract class is not there they have not been derived, yet, but you know what I mean). In these cases, the abstract class is usually used as a place where you can put any kind of common code that current derived classes contain.

For your second example, I think that using abstract classes isn't the optimal choice, because there are superior methods for dealing with shared logic and duplicated code. Let's say you have abstract class A, derived classes B and C and both derived classes share some logic in the form of method s(). To decide on the correct approach to get rid of the duplication, it is important to know, whether method s() is part of the public interface or not.

If it is not (as in your own concrete example with method b()), the case is quite simple. Just create a separate class from it, also extracting the context that is needed to perform the operation. This is a classic example of composition over inheritance. If there is little or no context needed, a simple helper function might already be enough as suggested in some comments.

If s() is part of the public interface, it becomes a bit more tricky. Under the assumption that s() has nothing to do with B and C being related to A, you shouldn't put s() inside A. So where to put it then? I would argue for declaring a separate interface I, which defines s(). Then again, you should create a separate class that contains the logic for implementing s() and both B and C depend on it.

Last, here is a link to an excellent answer of an interesting question on SO that might help you to decide when to go for an interface and when for an abstract class:

A good abstract class will reduce the amount of code that has to be rewritten because it's functionality or state can be shared.

Answer 5

First case, from your question:

In such cases, an abstract class works like a blueprint, a high level description of the functionality or whatever you wanna call it.

Second case:

Some other times ... the abstract class is usually used as a place where you can put any kind of common code that current derived classes contain.

Then, your question:

I am wondering which of these two cases should be the rule. ... Should code that may have no meaning for the abstract class itself be there just because it happens to be common for the derived classes?

IMO you have two different scenarios, therefore you cannot draw a single rule to decide what design must be applied.

For the first case, we have things like Template Method pattern already mentioned in other answers.

For the second case, you gave the example of abstract class A receiving a b() method; IMO the b() method should only be moved if it makes sense for ALL the other derived classes. In other words, if you're moving it because it's used in two places, probably this is not a good choice, because tomorrow there might be a new concrete Derived class on which b() makes no sense at all. Also, as you said, if you look at A class separately and b() also makes no sense in that context, then probably it's a hint that this is not a good design choice as well.

Answer 6

I've had exactly the same questions some time ago!

What I came to is whenever I stumble upon this issue I find that there is some hidden concept that I haven't found. And this concept more probably than not should be expressed with some value-object. You have very abstract example, so I'm afraid I can't demonstrate what I mean using your code. But here is a case from my own practice. I had two classes that represented a way to send request to external resource and parse the response. There were similarities in how the requests were formed and how the responses were parsed. So that's how my hierarchy looked like:

abstract class AbstractProtocol
{
    /**
     * @return array Registration params to send
     */
    abstract protected function assembleRegistrationPart();

    /**
     * @return array Payment params to send
     */
    abstract protected function assemblePaymentPart();

    protected function doSend(array $data)
    {
        return
            (new HttpClient(
                [
                    'timeout' => 60,
                    'encoding' => 'utf-8',
                    'language' => 'en',
                ]
            ))
                ->send($data);
    }

    protected function log(array $data)
    {
        $header = 'Here is a request to external system!';
        $body = implode(', ', $this->maskData($data));
        Logger::log($header . '. \n ' . $body);
    }
}

class ClassicProtocol extends AbstractProtocol
{
    public function send()
    {
        $registration = $this->assembleRegistrationPart();
        $payment = $this->assemblePaymentPart();
        $specificParams = $this->assembleClassicSpecificPart();

        $dataToSend =
            array_merge(
                $registration, $payment, $specificParams
            );

        $this->log($dataToSend);

        $this->doSend($dataToSend);
    }

    protected function assembleRegistrationPart()
    {
        return ['hello' => 'there'];
    }

    protected function assemblePaymentPart()
    {
        return ['pay' => 'yes'];
    }
}

Such code indicates that I simply misuse inheritance. That's how it could be refactored:

class ClassicProtocol
{
    private $request;
    private $logger;

    public function __construct(Request $request, Logger $logger, Client $client)
    {
        $this->request = $request;
        $this->client = $client;
        $this->logger = $logger;
    }

    public function send()
    {
        $this->logger->log($this->request->getData());
        $this->client->send($this->request->getData());
    }
}

$protocol =
    new ClassicProtocol(
        new PaymentRequest(
            new RegistrationData(),
            new PaymentData(),
            new ClassicSpecificData()
        ),
        new ClassicLogger(),
        new ClassicClient()
    );

class RegistrationData
{
    public function getData()
    {
        return ['hello' => 'there'];
    }
}

class PaymentData
{
    public function getData()
    {
        return ['pay' => 'yes'];
    }
}

class ClassicLogger
{
    public function log(array $data)
    {
        $header = 'Here is a request to external system!';
        $body = implode(', ', $this->maskData($data));
        Logger::log($header . '. \n ' . $body);
    }
}
class ClassicClient
{
    private $properties;

    public function __construct()
    {
        $this->properties =
            [
                'timeout' => 60,
                'encoding' => 'utf-8',
                'language' => 'en',
            ];
    }
}

Since then I treat inheritance very carefully cause I was hurt many times.

Since then I came to another conclusion about inheritance. I'm strongly against inheritance based on internal structure. It breaks encapsulation, it's fragile, it's procedural after all. And when I decompose my domain the right way, inheritance simply doesn't happen very often.