Naming convention for non-virtual and abstract methods

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

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.

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

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.