'OOD, inheritance, and Layer Supertype

I have a question concerning holding common code in a base class and having the derived class call it, even though the derived class's trigger method has been dispatched from the base. So, base->derived->base type call stack.

Is the following look OK, or does it smell? I have numbered the flow steps...

public abstract class LayerSuperType
{
  public void DoSomething()  // 1) Initial call from client
  {
    ImplementThis(); // 2) Polymorphic dispatch
  }

  protected abstract void ImplementThis();

  protected void SomeCommonMethodToSaveOnDuplication(string key)  // 4)
  {
    Configuration config = GetConfiguration(key);
  }
}

public class DerivedOne : LayerSuperType
{
  protected virtual void ImplementThis() // 2)
  {
    SomeCommonMethodToSaveOnDuplication("whatever");  // 3) Call method in base
  }
}

public class DerivedTwo : LayerSuperType
{
  protected virtual void ImplementThis() // 2)
  {
    SomeCommonMethodToSaveOnDuplication("something else"); // 3) Call method in base
  }
}
c++sharpoopinheritancepolymorphism


Solution 1:[1]

Looks like a very simplified Template Method Pattern where your sub-classes do some specific kinds of things at the right points in the implementation of your algorithm, but the overall flow is directed by a method on the base class. You've also provided some services to your sub-classes in the form of base class methods; that's ok too as long as you're good as far as SOLID goes.

Solution 2:[2]

That looks absolutely fine. Perfect example of why you'd use an abstract class over an interface. It's a bit like a strategy pattern and I have used this fairly regularly and successfully.

Make sure that what the class doing is still dealing with one 'concern' though, only doing one task. If your base class does repository access but the objects are representing documents, don't put the functionality in the base class, use a separate repository pattern/object.

Solution 3:[3]

Why not public abstract void DoSomething() and forget about ImplementThis() altogether?

The only reason I can see to leave ImplementThis() is if you want to maintain a consistent interface with DoSomething() which later on down the road will allow the signature of ImplementThis() to change without a breaking change to callers.

I agree that you should maintain a single concern with the class's responsibility but from an overall OOP perspective this looks fine to me. I've done similar on many occasions.

Solution 4:[4]

It does smell a little that SomeCommonMethodToSaveOnDuplication is being called in two different ways. It seems to be doing two unrelated things. Why not have two methods?

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Kit
Solution 2 Kieren Johnstone
Solution 3 harlam357
Solution 4 Vahid Farahmandian

Related Questions