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.
Superior
interface necessarily have more methods than on theStandard
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 theStandard
implementation to return unsupp – rwong Aug 7 '13 at 4:37