abstract method signature, inheritance, and "Do" naming convention

Question

I'm learning about design patterns and in examples of code I've seen a convention where the abstract class declares a method, for example:

public abstract class ServiceBase {
... 

public virtual object GetSomething();

and then

protected abstract object DoGetSomething();

My question is on why these two methods exist, since they appear to serve the same purpose. Is this so that the base class GetSomething() method logic cannot be overridden by inherited classes? But then again, the method is marked virtual, so it can be overridden anyway. What is the usefulness here in requiring derived class implementers to implement the abstract method when the virtual method can be called anyway?

Answer 1

One common reason is to put standard handling around the abstract method. For example, perhaps the abstract method can only be called in certain circumstance -- say, after the splines have been reticulated. In that case, it makes sense to check _areSplinesReticulated in one place -- the public GetSomething method -- rather than requiring every implementation of the abstract method to perform its own checking. Or maybe GetSomething is 90% boilerplate but requires a bit of additional logic or a crucial piece of information that only derived classes can supply.

This is a form of the Template Method pattern.

A non-virtual GetSomething means every derived class gets the standard handling and only gets to participate via their custom version of DoGetSomething. If GetSomething is virtual, that means derived classes can bypass the standard handling if they want to. Either of these is a viable strategy depending on whether the standard GetSomething handling is integral to the class logic (e.g. invariants) or whether the base class wants to grant maximum flexibility to derived classes.

Answer 2

I've not seen the version you describe where "GetSomething()" is virtual, but I've seen (and written) classes like this:

public abstract class Foo
{
    protected abstract void DoBar();

    public void Bar()
    {
        // do stuff that has to happen regardless of how 
        // DoBar() has been implemented in the derived
        // class
        DoBar();
        // do other stuff
    }
}

Because "Bar" isn't virtual (and I suppose you could also seal it just to make sure) you have a chance to "inject" code before and after the "DoBar" method is called. It's quite handy.