Extension points via inheritance vs via delegate fields

Beware: the following is giving you only a rough "rule of thumb" which is surely not a complete tutorial on how to use inheritance correctly, but you can use it as a first "litmus test" for what you were asking.

To create behavioural extension points, a popular classic approach is the strategy pattern. When you look at the pattern in full, you find both in it:

• An abstract behaviour (the strategy) which is injected like a delegate into a context class. In your "Animal" example, this could be an interface or abstract base class ISpeakStrategy, with derivations like DogSpeakStrategy or CatSpeakStrategy, where an ISpeakStrategy object is injected into a context object Animal.

• Inheritance to allow the extension of the set of available strategies, without touching any existing code.

Now there are situations where you may need extension points, but using the strategy pattern this way makes things more complex than necessary:

1. when the strategy interface requires only a single method, and the name of the interface is not really important, then using a single delegate instead of a full-blown inheritance hierarchy is usually suffient

2. when a separation between a "context" object and a strategy is not required, because the context class would be trivial / almost empty, then using a stand-alone inheritance hierarchy is sufficient.

So think of how the extension point would look like with the strategy pattern, then consider to leave out everything which overcomplicates your design.

Using a "delegate" method (e.g. an Action), you attain a larger degree of flexibility because the "injected" Action can be manipulated from a distance. This offers a fully decoupled behavior, so you can "fine-tune" instance behavior without ever meeting the class instance again after instantiation.

So, you can do something like the following:

//Application Root
BarkOptions barkOptions = new BarkOptions()
{
    BarkVolume = 40;
}

Action barking = () =>
{
   Console.WriteLine("Woofed at " + barkOptions.BarkVolume + " dB");

   //BarkVolume is a variable that is controlled by a distant "options" object,
   //which may be available, for example, through some Options panel in your
   //application, for the user to control. Therefore, between each call to
   //wolf.Bark(), the volume may have been changed, thus providing more control.
}

Animal wolf = new Animal(barking);

//Then, the two objects take their separate ways down your object graph.

Bear in mind that, yes, this is powerful, but sometimes, this might not be what you want, of course. If this is not what you want and you simply want to encapsulate the behaviour entirely within the class, you are clearly looking at simply creating methods and overriding them in derived classes.

Beyond that, do take Doc Brown's answer seriously, there are better options than those you propose.

When you write a class, you first follow the YAGNI principle: Don’t plan for extensibility because You Ain’t Gonna Need It. And because you have no clue right now how that extensibility might work.

Once you need to extend your class, you know what you are going to need. Usually the best is to add a property which might be a Boolean, or other simple value, or a delegate, or just a closure. Then modify the class to react properly to that property. Add documentation what happens if the property isn’t set (for example: if the background Color property is not set, then “white” is used).

Note that using inheritance means that you lose the freedom to modify the class without modifying its subclasses, and delegates or closures allow you to specifically address the differences between two instances without any surrounding code.