abstract method use vs regular methods

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 w开发者_开发问答ithout abstract methods

   but adding the relevant method later on the level of the derived classes.

What is the difference?

---

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.

---

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.

---

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").

---

Uhm, well, the difference is that the base class would know about the former, and not about the latter.

In other words, with an abstract method in the base class, you can write code in other methods in the base class that call that abstract method.

Obviously, if the base class doesn't have those methods... you can't call them...

---

An abstract function can have no functionality. You're basically saying, any child class MUST give their own version of this method, however it's too general to even try to implement in the parent class. A virtual function, is basically saying look, here's the functionality that may or may not be good enough for the child class. So if it is good enough, use this method, if not, then override me, and provide your own functionality...

And of course, if you override a virtual method, you can always refer to the parent method by calling base.myVirtualMethod()

---

Okay, when you see a method like this:

A.Foo();

What you really have (behind the scenes) is a signature like this.

Foo(A x);

And when you call A.Foo() you're really calling Foo(this) where this is a reference to an object of type A.

Now, sometimes you'd like to have Foo(A|B|C|D...) where Foo is a method that can take either a type A, or B, or C, or D. But you don't want to worry about what type you're passing, you just want it to do something different based on the type that was passed in. Abstract methods let you do that, that's their only purpose.