Avoiding the call to protected member of base class

Question

Here's a silly example of a tree structure where every node does a different kind of an action, but exactly one node (any node) has to do some common work at the start and end of a project.

public abstract class Employee
{
    public void StartProject()
    {
        AnnounceProjectToNewspapers();
        DoActualWork();
        PutProductOnMarket();
    }

    protected abstract void DoActualWork();

    private void AnnounceProjectToNewspapers() { }
    private void PutProductOnMarket() { }
}

public class Engineer : Employee
{
    protected override void DoActualWork()
    {
        // Build things.
    }
}

public class Salesman : Employee
{
    protected override void DoActualWork()
    {
        // Design leaflets.
    }
}

public class Manager : Employee
{
    protected override void DoActualWork()
    {
        // Make gantt charts.

        // Also delegate.
        foreach (var subordinate in subordinates)
            // ...but then compiler stops you.
            subordinate.DoActualWork();
    }

    private List<Employee> subordinates;
}

The problem is, you can't call the protected method DoActualWork() on a base class.

Two solutions I see are:

• Make DoActualWork() public. But this would allow anyone to call it without AnnounceProjectToNewspapers() or PutProductOnmarket().
• Make DoActualWork() internal. But this would prevent other assemblies from using the "management system".

Is there a standard work-around people use to avoid this limitation?

Answer 1

I have a couple of ways to achieve what you need.

1. The first and obvious way is to inherit Engineer and Salesman from Manager instead of employee. But this makes the inheritance sound ridiculous. Every Engineer is a Manager (I wish that was true.)

2. As you've mentioned,

Make DoActualWork() public

This does work. To then prevent any other method from calling DoActualWork() you could find out the type of the class using reflection/stacktrace and block invalid types. Refer here

But both these methods feel clanky to me. There should definitely be a way to design the classes to get what you need.

Answer 2

I came up with a solution like this (this has not been tested)

public interface IEmployee {
    void StartProject();
    void DoWork();
}

public abstract class EmployeeBase : IEmployee {
    public void StartProject() {
        AnnounceProjectToNewspapers();
        DoActualWork();
        PutProductOnMarket();
    }

    void IEmployee.DoWork() {
        // Maybe set a flag to see whether the work has been already done by calling StartProject().
        this.DoActualWork();
    }

    protected abstract void DoActualWork();

    private void AnnounceProjectToNewspapers() { }
    private void PutProductOnMarket() { }
}

public class Employee : EmployeeBase {
    protected override void DoActualWork() {
        // Log system Action
    }
}

public class Engineer : Employee {
    protected override void DoActualWork() {
        // Build things.
    }
}

public class Salesman : Employee {
    protected override void DoActualWork() {
        // Design leaflets.
    }
}

public class Manager : Employee {
    protected override void DoActualWork() {
        DoWorkInternal();
    }

    private void DoWorkInternal() {
        foreach (var subordinate in subordinates)
            subordinate.DoWork();
    }

    private List<IEmployee> subordinates;
}

Answer 3

Thinking about all the responses, a compromise just crossed my mind: use an indirect call through an internal method. In other words, a poor man's friend declaration by informal comments.

Here are the relevant bits:

public abstract class Employee
{
    // Meant to be called by Manager class only.
    internal void FollowTheLeader()
    {
        DoActualWork();
    }
}

public class Manager : Employee
{
    protected override void DoActualWork()
    {
        // Make gantt charts.

        // Also delegate.
        foreach (var subordinate in subordinates)
            // ...but then compiler stops you.
            subordinate.FollowTheLeader();
    }
}

Deriving classes from other assemblies will be able to customize the work Employees and Managers do, but they will not be able to make anyone do work without proper context.

Classes from within the assembly will be able to do anything, but let's assume you can trust the people developing the framework to follow the instructions in comments.