Naming convention for non-virtual and abstract methods

Question

I frequently find myself creating classes which use this form (A):

abstract class Animal {
  public void Walk() {
    // TODO: do something before walking

    /         


        

Answer 1

I'm not sure if there is a standard naming convention for this. Besides WalkInternal, other alternatives might be DoWalk or WalkImpl.

Answer 2

Btw, is there a name for this design pattern?

Your first example uses aspects of the Template Method pattern and is similar to what Herb Sutter calls the "Non-virtual Interface Idiom":

• http://www.gotw.ca/publications/mill18.htm

Answer 3

I prefer to name my virtual or abstract methods with the suffix Core, to indicate, that the method should contain the core logic to do something.

All argument checks and raising possible events I do in the method, that calls the Core-Methods.

  abstract class Animal {
    public void Walk() {
      // TODO: do something before walking 
      // possible Argument checks and event raising

      // custom logic implemented by each subclass
      WalkCore();

      // TODO: do something after walking
    }

    protected abstract void WalkCore();
  }

  class Dog : Animal {
    protected override void WalkCore() {
      // TODO: walk with 4 legs
    }
  }

  class Bird : Animal {
    protected override void WalkCore() {
      // TODO: walk with 2 legs
    }
  }

I think there is no offical naming guideline for this, and it´s up to you. But it should be consistent for all classes and virtual/abstract methods you define.

The "Framework Design Guidelines" suggest to use the Core suffix if you follow the Template Method and want to provide extensibility points.

Answer 4

Good question. The pattern is valid and I use it a lot. I also agree that WalkInternal is not an ideal name.

In this example I believe you are not framing the problem correctly.

Rather than renaming the 'internal' method, look at your 'external' public method. It's called Walk, but it has code snippets (//do something before walking and //do something after walking) which clearly shows that it contains more than just the logic for 'Walking'. Maybe this method should be called Exercise or GoToTheShops - or whatever creative name you can think of that describes what you are doing. Whatever the method is, it's definitely a superset of Walking + some other pre / post walking actions.

A similar example that I've recently developed had a public method called Complete, and a virtual called Save, so that:

• Every class needed to 'Complete'
• Different implementations would have their own 'Save' method
• 'Complete' would also perform some validation, notification, etc

In summary, the abstract method should be called Walk, and instead you should rename your public method to something that more accurately describes the 'do something / Walk / do something' process.

---

edit: If the Walk class doesn't add any significant value or logic to the WalkInternal class then I would question whether it is required. If it does add logic, then it should be renamed to reflect its new function.

Answer 5

I use the convention of an underscore capitalized case for abstract overrides, so Dog._Walk, although I more than occasionally wonder if there wasn't a better way.

I like DoWalk better than WalkInternal - it's shorter & conveys the idea that its an override quickly and upfront. "Do" anything kind of rubs me the wrong way though, kind of like "My" object does. I like my underscore followed by capital letter convention best, still.

Good real life question though

Cheers,
Berryl

Answer 6

For a method that provides a template method's primary behavior, I use names like WalkOverride. The base class implements it as either a protected abstract method (derived class is required to provide implementation) or a protected virtual empty/non-empty one (derived class may optionally provide/override implementation). Examples can be found in Microsoft's various XAML frameworks with methods such as MeasureOverride and ArrangeOverride. (The WalkCore pattern @Jehof mentions is used there to name the template method itself.)

For "events" to which the derived class can optionally respond for its own purposes (as opposed to defining the template method's behavior), I use names like OnWalking and OnWalked. Each of these is usually implemented in the base class as a protected virtual method with an empty method body.