(Regular Class + interface) vs Abstract class

Question

I recently encountered a question on abstract class.

Functionality of Abstract classes can be achieved by using combination of (Regular class with Protected Constructor + an interface).

What is the benefit of using Abstract Class over (Regular class with protected constructor + interface).

IMHO, Purpose of Abstract class to have common feature that needs to be available across the class hierarchy. It can pose restriction on sub-classes to implement certain features by Abstract methods. It can allow Sub-Classes to override the common behavior.

Abstract Class doesn't serve a purpose of as concrete object. So, It doesn't allow to instantiate the abstract class.

However,We can achieve same thing using Regular Class + interface.

1. Mark Regular Class constructor as protected, So object can't be created alone
2. provide default implementation of common features and mark them virtual in case if they need to be overridden by sub class.
3. Use interface to force sub-classes to implement certain features.

So, Is there any extra feature which Abstract class offer?

I could not think of any other. Interviewers was trying to know what other benefits Abstract class have over Regular Class with protected constructor + interface.

Answer 1

A lot of good reasons. Let's start with an unambiguous one:

public abstract class Smell
{
    public abstract string GetAdjective();
    public string GetDescription()
    {
        return "I smell " + GetAdjective();
    }
}
public class NastySmell : Smell
{
    public override string GetAdjective() { return "really nasty"; }
}

Pretty simple. The abstract class has a function, GetDescription - which relies on the presence of an abstract method GetAdjective.

How could you do this with ProtectedConstructor+Interface? You can't have Smell implement the interface (for lots of reasons, but a big one being that any derived classes would also inherit the implementation and wouldn't be required to implement anything new) - but that means that it's function can't refer to the method:

public interface SmellInterface
{
    string GetAdjective();
}
public class Smell
{
    protected Smell() { }
    public string GetDescription()
    {
        // how do I call GetAdjective here?  I have no reference to it!
    }
}

But here's another, even more compelling reason:

public abstract class SomeFancyClass
{
    protected string name;
    protected string server;
    protected abstract string implementer { get; }
    public string Generate()
    {
        if (name == "something")
            HandleGlobally(name);
        else
            HandleSpecifically(name);
    }
    public void HandleGlobally(string server)
    {
        // code
    }
    public abstract void HandleSpecifically(string server);
}

... if you make this class a combo ProtectedConstructorClass + Interface, you split up code into two separate spots - and suddenly, you have to look through two halves to get the full picture of what's going on!

public interface AbstractHalf
{
    // data property of 'implementer'
    // method of 'HandleSpecifically()
}
public class NonabstractHalf
{
    // data fields of 'name' and 'server'
    // methods of 'Generate()' and 'HandleGlobally'
}

... why would you want to do this? Your class is a distinct, logical entity. Why would you split it up into two separate parts: the non-abstract versus the abstract? It'd just make it harder to read and troubleshoot. And it'd get worse, the more code and abstract declarations were made in the class.

Answer 2

One thing that I can think of is that by using an abstract class you can force a specific implementation simply by not marking a method or property as virtual, while using an interface you can't prevent classes from implementing the interface but not derive from your base class.

Another benefit of using an abstract class is that you can simply add functionality to your abstract class without having to worry about having all your derived classes implementations - again, since you can't prevent a class from implementing an interface without deriving from your base class.

Also, an abstract class can have protected fields, methods, events etc', but an interface can't.

It all boils down to the fact that you can't force classes that implement your interface to derive from your "regular" base class.

Answer 3

The main benefit of the abstract class is to force the developer to create a subclass that inherits from the abstract class in order to use base/shared functionality and fields.

You cannot directly new-up an abstract class. You can new-up a regular class + interface, and you are not forced to inherit or override anything in the base.

With an abstract class, you can reduce the number of files - i.e. no interfaces, but most folks would probably like to keep those for registration with an IoC container and dependency injection.

Answer 4

First of all, there is many questions and answers about differences between Abstract Class and Interfaces like: this. There are a lot of remarkable answers. But most of them are about programming and syntax.

I want to look from Design Perspective:

I think that Abstract Class can not play the Role of Interface (+ Regular Class) in Software Design.

Abstract Class:
The main goal of Abstract Class is Abstraction Principle. To overcome this complexity, Abstract classes are used to make Hierarchies in similar looking classes. All classes in the hierarchy are extending base classes functionalities and extending types of base classes.

Interface:
However, Interfaces are used for Interactions between classes. These classes can be similar or not. They can be from different hierarchies and different types.

Also, they are huge difference between inheriting from a class (even Abstract class) and implementing an interface. Interfaces are not TYPES. They are shared boundary across which two or more separate components of a computer system exchange information.