3

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.

  • 1
    How about creating an abstract class or interface for the ProjectSectionBase and implement both derived classes with it. What type of extra functionality do you have? I really like the single responsibility principle meaning remove the extra functionality from the extended class... – PmanAce Aug 6 '13 at 15:07
  • 1
    can you give an example of extraFunctionality that is not in Standard class – k3b Aug 6 '13 at 15:30
  • 2
    Strategy pattern encapsulates a 'swappable' algorithm (same interface). For example with encryption you would have several different sub classes of specific encryption algorithms. For this reason it doesn't sound like you are using the strategy pattern but this is more like a problem with deciding how to effectively use inheritance / polymorphism. – Despertar Aug 7 '13 at 2:36
  • Echoing @Despertar 's concern, here is one question to ask. Suppose you were to create an API interface (one or two) for ProjectSectionStandard and ProjectSectionSuperior. All other code that calls into these classes must go through this one or two interfaces. Would the Superior interface necessarily have more methods than on the Standard interface? If so, they may not belong to the same inheritance hierarchy. If this is done so for application feature licensing control, one approach is for both to implement the feature-rich interface, and for the Standard implementation to return unsupp – rwong Aug 7 '13 at 4:37
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.

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.

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.