Are abstract classes / methods obsolete?

Question

I used to create a lot of abstract classes / methods. Then I started using interfaces.

Now I am not sure if interfaces aren't making abstract classes obsolete.

You need a fully abstract class? Create an interface instead. You need an abstract class with some implementation in it? Create an interface, create a class. Inherit the class, implement the interface. An additional benefit is that some classes may not need the parent class, but will just implement the interface.

So, are abstract classes / methods obsolete?

Answer 1

No.

Interfaces cannot provide default implementation, abstract classes and method can. This is especially usefull to avoid code duplication in many cases.

This is also a really nice way to reduce sequential coupling. Without abstract method/classes, you cannot implement template method pattern. I suggest you look at this wikipedia article : http://en.wikipedia.org/wiki/Template_method_pattern

Answer 2

An abstract method exists so you can call it from within your base class but implement it in a derived class. So your base class knows:

public void DoTask()
{
    doSetup();
    DoWork();
    doCleanup();
}

protected abstract void DoWork();

That's a reasonably nice way to implement a hole in the middle pattern without the derived class knowing about the setup and cleanup activities. Without abstract methods, you'd have to rely on the derived class implementing DoTask and remembering to call base.DoSetup() and base.DoCleanup() all the time.

Edit

Also, thanks to deadalnix for posting a link to the Template Method Pattern, which is what I've described above without actually knowing the name. :)

Answer 3

No, They are not obsolete.

In fact, there is an obscure but fundamental difference between Abstract Classes/Methods and Interfaces.

if the set of classes in which one of these has to be used have a common behaviour that they share (related classes, i mean), then go for Abstract classes/methods.

Example: clerk, Officer, Director -all these classes have CalculateSalary() in common, use abstract base classes.CalculateSalary() canbe differently implemented but there are certain other things like GetAttendance() for example which has a common definition in base class.

If your classes have nothing common(Unrelated classes, in the context chosen) in between them but has an action that is greatly different in implementation, then go for Interface.

Example: cow, bench, car, telesope-not related classes but Isortable can be there to sort them in an array.

This difference is usually ignored when approached from a polymorphic perspective. But I personally feel that there are situations where one is an apt than the other for the reason explained above.

Answer 4

In addition to the other good answers, there is a fundamental difference between interfaces and abstract classes that no one has mentioned specifically, namely that interfaces are far less reliable and therefore impose a much greater test burden than abstract classes. For example, consider this C# code:

public abstract class Frobber
{
    private Frobber() {}
    public abstract void Frob(Frotz frotz);
    private class GreenFrobber : Frobber
    { ... }
    private class RedFrobber : Frobber
    { ... }
    public static Frobber GetFrobber(bool b) { ... } // return a green or red frobber
}

public sealed class Frotz
{
    public void Frobbit(Frobber frobber)
    {
         ...
         frobber.Frob(this);
         ...
    }
}

I am guaranteed that there are only two code paths I need to test. The author of Frobbit can rely on the fact that the frobber is either red or green.

If instead we say:

public interface IFrobber
{
    void Frob(Frotz frotz);
}
public class GreenFrobber : IFrobber
{ ... }
public class RedFrobber : Frobber
{ ... }

public sealed class Frotz
{
    public void Frobbit(IFrobber frobber)
    {
         ...
         frobber.Frob(this);
         ...
    }
}

I now know absolutely nothing about the effects of that call to Frob there. I need to be sure that all the code in Frobbit is robust against any possible implementation of IFrobber, even implementations by people who are incompetent (bad) or actively hostile to me or my users (far worse).

Abstract classes allow you to avoid all these problems; use them!

Answer 5

You say it yourself:

You need an abstract class with some implementation in it? Create an interface, create a class. Inherit the class, implement the interface

that sounds a lot of work compared to 'inherit the abstract class'. You can make work for yourself by approaching code from a 'purist' view, but I find I have enough to do already without trying to add to my workload for no practical benefit.

Answer 6

As I commented on @deadnix post: Partial implementations are an anti-pattern, despite the fact that template pattern formalizes them.

A clean solution for this wikipedia example of the template pattern:

interface Game {
    void initialize(int playersCount);
    void makePlay(int player);
    boolean done();
    void finished();
    void printWinner();
}
class GameRunner {
    public void playOneGame(int playersCount, Game game) {
        game.initialize(playersCount);
        int j = 0;
        for (int i = 0; !game.finished(); i++)
             game.makePlay(i % playersCount);
        game.printWinner();
    }
} 
class Monopoly implements Game {
     //... implementation
}

This solution is better, because it uses composition instead of inheritance. The template pattern introduces a dependency between the implementation of the Monopoly rules and the implementation of how games are to be run. However these are two entirely different responsibilities and there is no good reason to couple them.

Answer 7

No. Even your proposed alternative includes the use of abstract classes. In addition, since you didn't specify the language, then I'm going to go right ahead and say that generic code is the better option than brittle inheritance anyway. Abstract classes have significant advantages over interfaces.

Answer 8

Abstract classes are not interfaces. They're classes that can't be instantiated.

You need a fully abstract class? Create an interface instead. You need an abstract class with some implementation in it? Create an interface, create a class. Inherit the class, implement the interface. An additional benefit is that some classes may not need the parent class, but will just implement the interface.

But then you would have a non-abstract useless class. Abstract methods are required to fill in functionality hole in the base class.

For example, given this class

public abstract class Frobber {
    public abstract void Frob();

    public abstract boolean IsFrobbingNeeded { get; }

    public void FrobUntilFinished() {
        while (IsFrobbingNeeded) {
            Frob();
        }
    }
}

How would you implement this base functionality in a class that has neither Frob() nor IsFrobbingNeeded?

Answer 9

I am a creator of servlet framework where abstract classes play essential role. I would say more, I need semi abstract methods, when a method needs to be overridden in 50% cases and I would like to see warning from compiler about that method wasn't overridden. I resolve the problem adding annotations. Returning back to your question, there are two different use case of abstract classes and interfaces, and no one is obsolete so far.

Answer 10

I don't think they're obsoleted by interfaces, but they might be obsoleted by the strategy pattern.

The primary use of an abstract class is to postpone a part of the implementation; to say, "this part of the class's implementation can be made different".

Unfortunately, an abstract class forces the client to do this via inheritance. Whereas the strategy pattern will allow you to achieve the same result without any inheritance. The client can make instances of your class rather than always defining their own, and the class's "implementation" (behaviour) can vary dynamically. The strategy pattern has the additional plus that behaviour can be changed at run-time, not only at design-time, and also has significantly weaker coupling between the types involved.

Answer 11

I've generally faced far, far, more maintenance problems associated with pure interfaces than ABCs, even ABCs used with multiple inheritance. YMMV -- dunno, maybe our team just used them inadequately.

That said, if we use a real world analogy, how much use is there for pure interfaces completely devoid of functionality and state? If I use USB as an example, that's a reasonably stable interface (I think we're at USB 3.2 now, but it has also maintained backwards compatibility).

Yet it's not a stateless interface. It's not devoid of functionality. It's more like an abstract base class than a pure interface. It's actually closer to a concrete class with very specific functional and state requirements, with the only abstraction being what plugs into the port being the only substitutable part.

Otherwise it would just be a "hole" in your computer with a standardized form factor and much looser functional requirements which wouldn't do anything on its own until every manufacturer came up with their own hardware to make that hole do something, at which point it becomes a much weaker standard and nothing more than a "hole" and a specification of what it should do, but no central provision for how to do it. Meanwhile we might end up with 200 different ways to do it after all hardware manufacturers try to come up with their own ways to attach functionality and state to that "hole".

And at that point we might have certain manufacturers that introduce different problems over others. If we need to update the specification we might have 200 different concrete USB port implementations with totally different ways of tackling the specification having to be updated and tested. Some manufacturers might develop de facto standard implementations they share amongst themselves (your analogical base class implementing that interface), but not all. Some versions might be slower than others. Some might have better throughput but worse latency or vice versa. Some might use more battery power than others. Some might flake out and not work with all hardware that's supposed to work with USB ports. Some might require a nuclear reactor to be attached to operate which has a tendency to give its users radiation poisoning.

And that's what I've found, personally, with pure interfaces. There might be some cases where they make sense, like just to model the form factor of a motherboard against a CPU case. Form factor analogies are, indeed, pretty much stateless and devoid of functionality, as with the analogical "hole". But I often consider it a huge mistake for teams to consider that to be somehow superior in all cases, not even close.

To the contrary, I think far more cases would be solved better by ABCs than interfaces if those are the two choices unless your team is so gigantic that it's actually desirable to have the analogical above equivalent of 200 competing USB implementations rather than one central standard to maintain. In a former team I was in, I actually had to fight hard just to loosen up the coding standard to allow ABCs and multiple inheritance, and mainly in response to these maintenance problems described above.