Design Pattern dilemma. Strategy seems wrong?

Question

I would like some help/advice on a design pattern or similar I could use for my problem.

I have some shared functionality in my code and I use the Strategy pattern at present. I have a base class named "ProjectSectionBase" and from here I have 2 derived classes, "ProjectSectionStandard" and "ProjectSectionSuperior". Now the problem is that "ProjectSectionSuperior" has a lot of extra functionality than "ProjectSectionStandard" and I'm finding that throughout my code i am calling methods like this:

DirectCast(_projectSection, ProjectSectionSuperior).DoSuperiorStuff

And I am also wrapping IF statements such as IF typeof(_projectSectio) is superior then.

It just feels like bad class design. Both standard and superior share a lot of common functionality but then Superior has so much more functionality. Any advice would be greatly appreciated.

Answer 1

What you describe is certainly not the Strategy Pattern. In Strategy all classes (of the strategy) have the same interface.

What you have is inheritance. The 'superior' should derive from 'standard' and then possibly override some virtual functions and add some additional methods and behavior. I am not sure if there is another pattern that can help you. Perhaps the State pattern, but it all depends on your requirements.

Since 'standard' and 'superior' are so very different you would ideally place a single IF statement somewhere in your logic and then have two entirely self-contained components that handle the particular situation. So, you apply some form of refactoring.

Answer 2

This is a common problem. Usually the problem is that your class has too many responsibilities. Consider:

public interface IProjectSection
{
    void DoSectionStuff()
}

public class SimpleProjectSection : IProjectSection
{
    public void DoSectionStuff(){/*simple stuff here*/}
}

public class SuperiorProjectSection: IProjectSection
{
    public void DoSectionStuff(){/*complex stuff here*/}
    public void DoSuperiorSectionStuff(){/*additional superior stuff here*/}
}

public class ProjectSectionUser
{
    public void DoSomeProjectSectionThings(IProjectSection section)
    {
        section.DoSectionStuff();
        var superior = section as SuperiorProectSection;
        if(superior != null)
            superior.DoSuperiorSectionStuff();
    }
}

This is actually nicer to represent as two strategy patterns, separating the DoSuperiorSectionStuff() into another interface, like so:

public interface IProjectSection
{
    void DoSectionStuff();
}

public interface ISuperiorProjectSection
{
    void DoSuperiorSectionStuff();
}

public class SimpleProjectSection : IProjectSection
{
    public void DoSectionStuff(){/*simple stuff here*/}
}

public class SuperiorProjectSection: IProjectSection, ISuperiorProjectSection
{
    public void DoSectionStuff(){/*complex stuff here*/}
    public void DoSuperiorSectionStuff(){/*additional superior stuff here*/}
}

public class ProjectSectionUser
{
    public void DoSomeProjectSectionThings(IProjectSection section, ISuperiorProjectSection superior)
    {
        section.DoSectionStuff();
        superior.DoSuperiorSectionStuff();
    }
}

Then the two ways to use it are:

...
var superiorSection = new SuperiorProjectSection();
projectSectionUser.DoSomeProjectSectionThings(superiorSection, superiorsection);
...

or

...
var superiorSection = new NullSuperiorProjectSection();
var section = new SimpleProjectSection();
projectSectionUser.DoSomeProjectSectionThings(section, superiorsection);
...

where NullSuperiorProjectSection is defined as

public class NullSuperiorProjectSection : ISuperiorProjectSection
{
    public void DoSuperiorSectionStuff(){/*do nothing*/}
}

Note: normally I would implement these two interfaces in separate classes. In this case, I don't know enough about your code to make a decent example that way, so i left it like this. Split separate responsibilities into separate classes where it makes sense; it increases your codes flexibility over time.

Answer 3

One solution would be that all functions are implemented as virtual in base class, and have empty bodies, and only superior class overrides them with meaningful code. One special function is bool IsSuperior() that returns false in base class and overridden in superior it returns true. All this just cleans the code a little bit. Maybe cleaning the code is just what you need, as code does not have to be perfect and idealistic, but needs to get the job done.