Template method pattern - prevent direct method calls in derived classes

Question

I'm not sure if I understand template method pattern correctly.

Here is my simplified base class implementation:

public abstract class AlgorithmBase
{
    protected void AlgorithmMethod()
    {
        if(!OnSimulationStart())
        {
            OnSimulationEnd(false);
            return;
        }

        if(!DoSomeStep())
        {
            OnSimulationEnd(false);
            return;
        }

        OnSimulationEnd(true);
    }

    protected abstract bool OnSimulationStart();
    protected abstract bool DoSomeStep();
    protected abstract void OnSimulationEnd(bool result);
}

As far as I understand it, base class knows algorithm flow and manages it. The problem is that in real project I have many abstract methods and it would be nice if I could somehow prevent direct calling them in derived classes. It is unreadable when more than one class manages algorithm flow.

Can you post a non-trivial example of a situation you are trying to prevent? Most likely you are failing to decompose your problem appropriately when you have to worry about improper use of those abstract methods. — Ondrej Tucny, Sep 30 '12 at 16:24
Base class knows general algorithm. Derived class is also abstract, but adds some async processing. In this point there are 3 different result types: good, error and cancel - all coming from DoSomeStep method implementation. OnSimulationStart can also return false (another error result). In OnSimulationEnd() implementation I don't know if flow was canceled or there was an error. Maybe base class algorithm should handle 3 end result types ? I caught myself several times calling overridden methods,that's why I posted this question. — Kuba, Sep 30 '12 at 16:51
template method is one of the problematic GOF patterns you should only use very carefully if at all. It can get hard to maintain and understand pretty quickly. — nansen, Sep 30 '12 at 22:16

score 1 · Accepted Answer · answered Sep 30 '12 at 16:39

A trick based on explicit implementation of an interface can be used to prevent accidental invokes of method required by the base algorith implementation. However, it's such a safety measure, which can be broken, but the chances are high that the developer would know what he would be doing.

An interface declaring methods required by AlgorithmMethod:

public interface IAlgorithmMethodImpl
{
    bool OnSimulationStart();
    bool DoSomeStep();
    void OnSimulationEnd(bool result);
}

Base abstract class that uses this interface, passed into its constructor, to call required methods:

public abstract class AlgorithmBase
{
    protected AlgorithmBase(IAlgorithmMethodImpl impl)
    {
        Impl = impl;
    }

    // can be a property reasonable cases; however, a field 
    // fits well into our scenario
    private IAlgorithmMethodImpl Impl; 

    protected void AlgorithmMethod()
    {
        if(!Impl.OnSimulationStart())
        {
            Impl.OnSimulationEnd(false);
            return;
        }

        if(!DoSomeStep())
        {
            Impl.OnSimulationEnd(false);
            return;
        }

        Impl.OnSimulationEnd(true);
    }

    // no abstract method declarations here — they are provided by 'Impl'
}

Then the specific algorithm class that inherits from AlgorithmBase uses explicit interface implementation to encapsulate implementation of the necessary methods (like with abstract methods declared in the base) class while preventing them being invoked accidentally:

public class MySuperAlgorithm : AlgorithmBase, IAlgorithmMethodImpl
{
    public MySuperAlgorithm()
        // pass a reference to this instance as the class 
        // that implements the required methods
        : base(this) 
    {
    }

    // explicit implementation of IAlgorithmMethodImpl
    bool IAlgorithmMethodImpl.OnSimulationStart() { ... implementation ... }
    bool IAlgorithmMethodImpl.DoSomeStep() { ... implementation ... }
    void IAlgorithmMethodImpl.OnSimulationEnd(bool result) { ... implementation ... }
}

The advantage of this approch — besides preventing accidental invoking of implementation methods — is that you can choose whether encapsulate the implementation in the descendant, or to decompose it into a separate class.

Nice trick :) The other thing I like in your example is that we could even go further and decouple AlgorithmBase derived class implementation from algorithm implementation. — Kuba, Sep 30 '12 at 17:09
Yes, decoupling is the quality you should seek in your implementation. If will future-proof your code. — Ondrej Tucny, Sep 30 '12 at 17:18

Template method pattern - prevent direct method calls in derived classes

1 Answers1