The Open-Closed Principle is a very powerful design principle and says that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”. In OOP, there are two types;
- Meyer’s Open/Closed Principle
- Polymorphic Open/Closed Principle
You can read about both of them here. I am partial to the Polymorphic Open/Closed Principle and will discuss its intention and provide a simple example.
The basis of Polymorphic Open/Closed Principle is abstract interfaces, where the implementations can be changed and multiple implementations can be created and polymorphically substituted for each other. This provides extension. However, the interface is closed to modifications. This allows a framework, no matter how big or small, to be defined that can rely on a particular interface to “do something” relevant to the interface. And through this interface, another entity can extend the framework through its behavior without any modification to the framework.
A great example demonstrating the Polymorphic Open/Closed Principle is a widget container framework that allows widgets to be easily added. You find this in Web 2.0 portals, blog software (WordPress), Rails (via plug-ins), etc… My example, in C#, is not meant to be a fully-blown widget framework, as my intention is to focus attention on minimal code demonstrating the Open-Closed Principle.
We’ll start with the following interface:
public interface IWidget
{
void Init(IWidgetContainer container);
void Close();
void Install();
void Uninstall();
void ShowSettings();
void HideSettings();
string Name { get; };
string Description { get; };
string Author { get; };
string Version { get; };
string SupportsFrameworkVersion { get; };
}
Let’s say our widget framework provides for the following:
- the installation and uninstallation of widgets
- the use of widgets within a widget container
- the initialization and closing of widgets
- the control of widget settings
Our widget framework might have a WidgetManager to manage widget installations, and WidgetContainers that actually use the widgets.
Let’s look at these classes.
public class WidgetManager
{
private IList<IWidget> widgets = new List<IWidget>();
public void Install(IWidget widget)
{
if (IsValid(widget))
{
this.widgets.Add(widget);
}
else
{
throw new InvalidWidgetException(widget);
}
}
public void Uninstall(IWidget widget)
{
this.widgets.Remove(widget);
}
public IWidgetContainer CreateWidgetContainer()
{
return new WidgetContainer("default-theme");
}
protected bool IsValid(IWidget widget)
{
return string.Compare(widget.SupportsFrameworkVersion, "v1.0") == 0;
}
}
public class WidgetContainer : IWidgetContainer
{
private IList<IWidget> widgets = new List<IWidget>();
private string theme;
public WidgetContainer(string theme)
{
this.theme = theme;
}
public AddWidget(IWidget widget)
{
widget.Init(this);
this.widgets.Add(widget);
}
public void Close()
{
foreach (IWidget widget in this.widgets)
{
widget.Close();
}
this.widgets.Clear();
}
public string Theme()
{
return this.theme;
}
}
And now we create two widgets. Note how the behavior of the widget is really contained within the widget, but the widget must adhere to the interface, or contract, agreed to by the widget framework.
public class WeatherWidget : IWidget
{
private string zipcode;
public Init(IWidgetContainer container)
{
string theme = container.Theme();
// dress up widget per theme...
}
public void ShowSettings()
{
// shows the settings, in our case, the zipcode
}
public void HideSettings()
{
// saves the zipcode and hides the settings
}
public void Close()
{
// save...
}
public void Install()
{
// for example, do any needed resource allocation
}
public void Uninstall()
{
// for example, do any needed resource deallocation
}
public string Name
{
get { return "WeatherWidget 3000"; }
}
public string Description
{
get { return "Provides nice weather forecasts."; }
}
public string Author
{
get { return "Brian Buikema"; }
}
public string Version
{
get { return "v2.0"; }
}
public string SupportsFrameworkVersion
{
get { return "v1.0"; }
}
}
public class CalendarWidget : IWidget
{
private int startYear = 1970;
public Init(IWidgetContainer container)
{
string theme = container.Theme();
// dress up widget per theme...
}
public void ShowSettings()
{
// show the settings, in our case, the start year
}
public void HideSettings()
{
// saves the start year and hides the settings
}
public void Close()
{
// save...
}
public void Install()
{
// for example, do any needed resource allocation
}
public void Uninstall()
{
// for example, do any needed resource deallocation
}
public string Name
{
get { return "CalendarWidget 3000"; }
}
public string Description
{
get { return "Provides a nice calendar." }
}
public string Author
{
get { return "Brian Buikema"; }
}
public string Version
{
get { return "v3.1"; }
}
public string SupportsFrameworkVersion
{
get { return "v1.0"; }
}
}
The framework allows for the installation of widgets and creation of containers as follows:
// install some widgets
widgetMgr.Install(new WeatherWidget());
widgetMgr.Install(new CalendarWidget());
// create a container
IWidgetContainer container = widgetMgr.CreateWidgetContainer();
And the framework allows for the use of widgets by the containers as follows:
// add some widgets to the container
container.AddWidget(weatherWidget);
container.AddWidget(calendarWidget);
// close container, effectively closing the widgets as well
container.Close();
I hope this simple “learn by code review” example helps enlighten those looking to advance their toolbox of design patterns and principles!

It’s really well done! Respect to author.