abstract method use vs regular methods

Question

I would like to know the difference between two conventions:

1. Creating an abstract base class with an abstract method which will be implemented later on the derived classes.
2. Creating an abstract base class without abstract methods
   but adding the relevant method later on the level of the derived classes.

What is the difference?

Solution 1

Much like interfaces, abstract classes are designed to express a set of known operations for your types. Unlike interfaces however, abstract classes allow you to implement common/shared functionality that may be used by any derived type. E.g.:

public abstract class LoggerBase
{
  public abstract void Write(object item);

  protected virtual object FormatObject(object item)
  {
    return item;
  }
}

In this really basic example above, I've essentially done two things:

1. Defined a contract that my derived types will conform to.
2. Provides some default functionality that could be overriden if required.

Given that I know that any derived type of LoggerBase will have a Write method, I can call that. The equivalent of the above as an interface could be:

public interface ILogger
{
  void Write(object item);
}

As an abstract class, I can provide an additional service FormatObject which can optionally be overriden, say if I was writing a ConsoleLogger, e.g.:

public class ConsoleLogger : LoggerBase
{
  public override void Write(object item)
  {
    Console.WriteLine(FormatObject(item));
  }
}

By marking the FormatObject method as virtual, it means I can provide a shared implementation. I can also override it:

public class ConsoleLogger : LoggerBase
{
  public override void Write(object item)
  {
    Console.WriteLine(FormatObject(item));
  }

  protected override object FormatObject(object item)
  {
    return item.ToString().ToUpper();
  }
}

So, the key parts are:

1. abstract classes must be inherited.
2. abstract methods must be implemented in derived types.
3. virtual methods can be overriden in derived types.

In the second scenario, because you wouldn't be adding the functionality to the abstract base class, you couldn't call that method when dealing with an instance of the base class directly. E.g., if I implemented ConsoleLogger.WriteSomethingElse, I couldn't call it from LoggerBase.WriteSomethingElse.

Solution 2

The idea of putting abstract methods in a base class and then implementing them in subclasses is that you can then use the parent type instead of any specific subclass. For example say you want to sort an array. You can define the base class to be something like

abstract class Sorter {
    public abstract Array sort(Array arr);
}

Then you can implement various algorithms such as quicksort, mergesort, heapsort in subclasses.

class QuickSorter {
    public Array sort(Array arr) { ... }
}

class MergeSorter {
    public Array sort(Array arr) { ... }
}

You create a sorting object by choosing an algorithm,

Sorter sorter = QuickSorter();

Now you can pass sorter around, without exposing the fact that under the hood it's a quicksort. To sort an array you say

Array sortedArray = sorter.sort(someArray);

In this way the details of the implementation (which algorithm you use) are decoupled from the interface to the object (the fact that it sorts an array).

One concrete advantage is that if at some point you want a different sorting algorithm then you can change QuickSort() to say MergeSort in this single line, without having to change it anywhere else. If you don't include a sort() method in the parent, you have to downcast to QuickSorter whenever calling sort(), and then changing the algorithm will be more difficult.

Solution 3

In the case 1) you can access those methods from the abstract base type without knowing the exact type (abstract methods are virtual methods).

The point of the abstract classes is usually to define some contract on the base class which is then implemented by the dervied classes (and in this context it is important to recognize that interfaces are sort of "pure abstract classes").

Comments

[Mulder]

Okay so when do I use the case 2? (Or I should never use it)

[Mulder]

@Mathew:You mean that the two scenarios do the same except I can use Polymorphism in the first scenario while in the second I cannot use in a polymorphic way?

[Matthew Abbott]

@Mulder - very much so. If you wanted to use the abstract base class like you would an interface, to call operations on it, you can only do so with methods in the abstract class itself (or any types it inherits from). E.g., you can call ToString on any object, because it is a member of System.Object.

[Lucero]

Sorry for the late answer. Case 2 is rarely used indeed, maybe in some very specific case where you want to use a common ancestor class but have no need for members on it.