Interface vs Abstract Class with an empty method

Question

I'm trying to understand when I should use an interface vs an abstract class. I was looking at improving my MVC application design and came across this article: http://www.codeproject.com/Articles/822791/Developing-MVC-applications-using-SOLID-principles

In the section about OCP the author gives an example about calculating the price of books. The original code looks like this:

enum Category
{
    student,
    corporate
}

class Book
{
    public double CalculatePrice(double price,Category category)
    {
        if (category == Category.corporate)
        {
            price = price- (price * 10);
        }
        else if (category == Category.student)
        {
            price = price - (price * 20);
        }

        return price;
    }

}

And his solution looks like this:

abstract class Book
{
    public abstract double CalculatePrice(double price);
}

class StudentBook : Book
{
    public override double CalculatePrice(double price)
    {
        return price - (price * 20);
    }
}

class CorporateBook : Book
{
    public override double CalculatePrice(double price)
    {
        return price - (price * 10);
    }
}

My questions while looking at this solution are:

1. Why use an abstract class here instead of an interface?
2. What difference would it make if you were to change this to an interface? Would it really matter?

Thanks for any help in understanding this

Answer 1

The example is artificial because the Book base class has no behaviour, it could just as well be an interface. However a more realistic example would have many other methods such as

getAuthor()
getISBN()
isFiction()

and presumably those behaviours do not change if the book is Student or Corporate so we have a base class with lots of standard behaviours. So Book would genuinely be a Class in that it has useful behaviours that are shared by its derived classes.

Things get a bit more complicated when you have several groups of behaviours, for example a Library Book is a Book but it is also a LendableThing and in Java you can't inherit from two different base classes.

In practice I find that have more Interfaces than I do Abstract Base classes. I define Interfaces as my outward facing contract. That is I write some code that works on objects that my callers give me. I tell them I need something that fulfils this Interface. I don't make any statement about how that is done, just give me something that can CalculatePrice.

The AbstractClass is more for the benefit of someone implementing some code. We're effectively giving a partially written class and then asking the coder to "fill in the blanks". Situations where we can usefully do that tend to be more rare.

Answer 2

In your case it would be more suitable using an interface rather than an abstract class. I say so, because you don't provide any implementation of your method that later may be overidden by the classes that inherit your abstract class. All you want it that either a CorporateBook and StudentBook have a method called CalculatePrice with the same signature. Hence, you could define an interface called

public interface IPriceCalculator
{
    public double CalculatePrice(double price);
}

and later just make your classes implement this interface:

class StudentBook : Book, IPriceCalculator
{
    public double CalculatePrice(double price)
    {
        return price - (price * 20);
    }
}

and

class CorporateBook : Book, IPriceCalculator
{
    public override double CalculatePrice(double price)
    {
        return price - (price * 10);
    }
}

On the other hand I would suggest another approach for calculating the value:

public interface IPriceCalculator
{
     public double CalculatePrice(double price);
}

public class PriceCalculator
{
    public double Discount { get; private set; }

    public PriceCalculator(double discount)
    {
        Discount = discount;
    }

    public double CalculatePrice(double price)
    {
        return price - (price*Discount)
    }
}

and later inject an object of type IPriceCalculator to the Book constructor.

public class Book
{
    // The initial price.
    public double Price { get; private set; }
    public IPriceCalculator PriceCalculator { get; private set; } 

    public Book(double price, IPriceCalculator priceCalculator)
    {
        Price = price;
        PriceCalculator = priceCalculator;
    }

    public double CalculatePrice()
    {
        return PriceCalculator.CalculatePrice(Price);
    }
}

Last,

class StudentBook : Book
{
    public StudentBook(double price, IPriceCalculator priceCalculator) : 
        base(double price, IPriceCalculator priceCalculator)
    {

    }
}

class CorporateBook : Book
{
    public CorporateBook(double price, IPriceCalculator priceCalculator) : 
        base(double price, IPriceCalculator priceCalculator)
    {

    }
}

and you create the PriceCalculator of your choice and pass them to the constructors of StudentBook and CorporateBook.

Answer 3

An interface is probably the best option in the example you have given, though that may change if the example is expanded.

Broadly speaking, both interfaces and abstract classes can be used to enforce contracts - ie., that a type implementing the contract should behave a certain way. The main difference is that an interface just says what the implementing type should be able to do, whilst abstract classes have the ability to share functionality in addition to a contract.

Your book example could be extended to have extra functionality that has the same implementation across all types of Book, and in that case, you would want to use an abstract class. For example, if I wanted to share an getISBN() method, but the implementation didn't change across the types implementing the contract, then it might make more sense to use an abstract class.

The limitation being that you can only ever implement a single abstract class on any given type but you may implement as many interfaces as you like.

I've seen a few examples where an abstract class implements an interface, and the concrete class implements the abstract class - This way, you get the best of both worlds; 3rd parties don't have to be coupled to your implementation of getISBN() on the abstract class.

Another tangential point is that some mocking libraries will struggle with mocking non-virtual methods and this includes methods on abstract classes - however, they will work perfectly fine with interfaces.

As a TLDR: interfaces are for types where you are not at all interested in how the implementation is done and you only care that a type has certain features. Use abstract classes when you care about how certain parts of the class are implemented but not others.

Answer 4

In C#, the difference between using an abstract class versus an interface is mostly about the limitation on polymorphism in CLS languages. In the example that you have given, because the two implementations of CalculatePrice are very simple, using an abstract class instead of an interface adds the polymorphism constraint to all derivatives of Book and brings almost no gain.

I understand that this is a highly simplified example, but hopefully the book will show how the calculation of the price of the book doesn't belong inside the book at all. The first principle of S.O.L.I.D. is Single Responsibility. It is by far the most important. The book class (and derivatives) calculating its price adds a second responsibility to the book (I'm assuming that containing content is the other, and primary, responsibility of the book). This violates the first principle. [It also violates other OOP "rules" like high class cohesion, but that is another topic].

If you wanted to provide access to the calculation of the price to the book class, you would make use of a separate calculating class in the book:

public interface IBookPriceCalculator
{
    double CalculatePrice(double price);
}

public class StudentBookPriceCalculator : IBookPriceCalculator
{
    public double CalculatePrice(double price)
    {
        return price - (price * 0.20);
    }
}

public class StudentBook
{
    IBookPriceCalculator _priceCalculator;

    public StudentBook()
    {
        _priceCalculator = new StudentBookPriceCalculator();
    }

    public double BasePrice { get; set; }

    public double GetPrice()
    {
        return _priceCalculator.CalculatePrice(BasePrice);
    }
}

Answer 5

The answer depends of some factors like common behaviors and level of extensibility. I'm going to explain it creating here an imaginary concept of social network so for us a social network is something that can post messages with images and save an history of posted messages. Then our social networks will share behavior so I will create a base class (abstract class).

public abstract class SocialNetwork
{
    public List<string> History { get; private set; }

    protected SocialNetwork()
    {
        History = new List<string>();
    }

    public void Post(string comment, byte[] image)
    {
        DoPost(comment, image);
        History.Add(comment);
    }

    protected virtual void DoPost(string comment, byte[] image)
    {
    }
}

Now I will create our social networks: facebook and twitter

public class Facebook : SocialNetwork
{
    protected override void DoPost(string comment, byte[] image)
    {
        //Logic to do a facebook post
    }
}

public class Twitter : SocialNetwork
{
    protected override void DoPost(string comment, byte[] image)
    {
        //Logic to do a twitter post
    }
}

Everything look fine until now. Well, imagine we have to handle a totally different kind of social network, for instance some social network that not store messages history, something like Snapchat:

public class Snapchat : SocialNetwork
{
    private string _lastMessage;

    protected override void DoPost(string comment, byte[] image)
    {
        //Logic to do a snapchat post
        _lastMessage = comment;
        ProcessLastMessage();
        History.Clear();
    }

    private void ProcessLastMessage()
    {
        //Some logic here.
    }
}

As you can note above the Snapchat class inherits from SocialNetwork class so Snapchat class will store a history of posts too. But we don’t want it so we have to put code to clear the history list.

Interfaces comes in action The problem with the implementation above is Snapchat have a thing he don’t need i.e the History so we need a higher level of abstraction here, SocialNetwork base class is what we know how a normal social network, but we need a super abstraction to define what a SocialNetwork do without define any behavior for it so we need define an interface.

public interface ISocialNetwork
{
    void Post(string message, byte[] image);
}

Now we will do SocialNetwork class to implement ISocialNetwork:

public abstract class SocialNetwork : ISocialNetwork
{
    ...     
    public void Post(string comment, byte[] image)
    {
        ...
    }
    ...
}

Now here is the new Snapchat class:

public class Snapchat : ISocialNetwork
{
    private string _lastMessage;

    public void Post(string message, byte[] image)
    {
        //Logic to do a snapchat post
        _lastMessage = message;
        ProcessLastMessage();
    }

    private void ProcessLastMessage()
    {
        //Some logic here.
    }
}

Now the design is powerfull enough. Facebook and Twitter share common behavior from SocialNetwork (abstract class) and it implements ISocialNetwork (interface). Snapchat class not share any behavior with Facebook and Twitter but it is a social network too so it implements directly ISocialNetwork interface.

You can read the full article from here: http://www.theagilethinker.com/2015/08/22/an-interesting-example-of-convivence-between-abstract-classes-and-interfaces/