Object-Oriented Design – Interface Dependencies vs Abstract Classes

abstract classcdesigninterfacesobject-oriented-design

I have a decision to make and I am wondering what would be the better solution. I am refactoring an older application and intend to really get into the nuts and bolts of it.

There are 8 report types currently and one of the modifications are to allow different reports to be "saved" in different ways. My two thoughts on it were

Have an Abstract Class with an abstract save method, then each report type can define its own way of doing things. Possibly have other abstract classes inheriting from that one, each implementing a virtual Save() method. Then the report classes can inherit from the one with the relevant save mechanism.
Have a report interface, which has a method signature like
```
void Save(ISaveMechanism saveMechanism);
```
Then have an interface with a Save() method, then each report type can use saveMechanism.Save(); and just use the concrete implementation required.

Would either solution cause more issues/drawbacks than the other? This project doesn't currently have any associated unit tests but if given time, it would be good to add some later.

Best Answer

I don't think it's an either/or. I think you should use both Interfaces and Abstract Classes.

TL;DR

Abstract Classes

Pros:

Relatively simple
You can provide basic functionality and "hooks" that the subclasses can use.

Cons:

You're "stuck" with the inheritance hierarchy
Client code knows about the Base Class

Interfaces

Pros:

Almost unlimited flexibility

Cons:

Zero implementation provided
May be harder for less experienced coders to understand.

Scenario

Imagine that you create an Abstract Class today. We'll call it BaseReport. BaseReport provides an empty "save" method, and all your current types of reports extend from BaseReport and have their own implementation of save.

For the sake of argument, you also want to display the text of the report before saving it, so your BaseReport extends a simple View component provided by your language of choice that will allow you to put a few text objects and a save button on the screen and not much more. It's really lightweight, so it's a good choice based on all the reports you have in front of you. I'll call it SimpleContainer.

Now, you're nine months down the line, and you need to have a report that has multiple pages, and someone has asked that one of the reports be viewable in either portrait or landscape modes. Neither of these requirements can be fulfilled with a subclass of SimpleContainer.

However, you have a lot of client code that knows about BaseReport, and there might even be a place or two where you've cast to SimpleContainer (where's the harm?). Not only that, the code is more like custom framework code, and you've spawned off four projects that use it. So all of those projects will have to go through QA again if you refactor to go to IReport so you can extend PagedContainer for the one report and RotatableContainer for the other. More than likely, at this point your answer is "sorry, we can't do that." Not because you really can't do that, but because it's too much of a risk to all the other things sitting on top of it.

But for the past 9 months, you've been developing along like gangbusters because you had that base code in BaseReport that allowed you to rip out a new Report type in record time, so you don't want to throw the baby out with the bathwater. Instead, make your BaseReport implement IReport and just make sure that the client code only refers to it as IReport. When the requirement comes in for a PagedContainer, build a BasePagedContainer that implements IReport and then build your individual reports on top.

There's not really a downside to this approach, because the amount of labor it takes to create the interface and implement it into your Abstract Classes is minuscule compared to the amount of flexibility and future-proofing you gain.

And I might have changed a few details to protect the innocent, but the scenario is real, and it happened to me. :)

Related Solutions

C# Design – When to Use Abstract Classes vs Interfaces with Extension Methods

When you need a part of the class to be implemented. The best example I've used is the template method pattern.

public abstract class SomethingDoer
{
    public void Do()
    {
        this.DoThis();
        this.DoThat();
    }

    protected abstract void DoThis();
    protected abstract void DoThat();
}

Thus, you can define the steps that will be taken when Do() is called, without knowing the specifics of how they will be implemented. Deriving classes must implement the abstract methods, but not the Do() method.

Extensions methods don't necessarily satisfy the "must be a part of the class" part of the equation. Additionally, iirc, extension methods cannot (appear to) be anything but public in scope.

edit

The question is more interesting than I had originally given credit for. Upon further examination, Jon Skeet answered a question like this on SO in favour of using interfaces + extension methods. Also, a potential downside is using reflection against an object hierarchy designed in this way.

Personally, I am having trouble seeing the benefit of altering a currently common practice, but also see few to no downsides in doing it.

It should be noted that it is possible to program this way in many languages via Utility classes. Extensions just provide the syntactic sugar to make the methods look like they belong to the class.

Php – Switching from abstract class to interface

That construction method should go in a new Factory class.

In object-oriented computer programming, a factory is an object for creating other objects. It is an abstraction of a constructor, and can be used to implement various allocation schemes. For example, using this definition, singletons implemented by the singleton pattern are formal factories.

A factory object typically has a method for every kind of object it is capable of creating. These methods optionally accept parameters defining how the object is created, and then return the created object.

Factory objects are used in situations where getting hold of an object of a particular kind is a more complex process than simply creating a new object. The factory object might decide to create the object's class (if applicable) dynamically, return it from an object pool, do complex configuration on the object, or other things...

Best Answer

TL;DR

Abstract Classes

Pros:

Cons:

Interfaces

Pros:

Cons:

Scenario

Related Solutions

C# Design – When to Use Abstract Classes vs Interfaces with Extension Methods

Php – Switching from abstract class to interface

Related Topic