New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

DotNetNuke Patterns and Practices - 3: The SOLID Design Principles

Many of the Patterns and Practices that will be discussed in this series rely on the so-called “SOLID” Design principles, so in this article in our series I will take a detour to introduce this very important set of principles.

S – Single Responsibility Principle

The Single Responsibility principle states that a Class (or a Method within a class) should have a single responsibility. 

For instance a method that is designed to Get something should not also Create something.  It should instead just indicate that the item does not exist and allow the caller of the method to take the appropriate action.  There are many ways it could indicate that the item doesn’t exist.  One is to return null or nothing - another is to throw a specific exception - perhaps a custom ItemNotFoundException. 

Robert Martin, when he introduced the so-called “SOLID” Design principles defined a responsibility as a reason to change, and he stated the a class or a module should have one, and only one reason to change.  For example a module what compiles and prints a report can be changed for two reasons - first, the content of the report can change, but second the format of the report can change.  This module therefore breaks the single responsibility principle and should be refactored into two modules - one to compile the report and one to print it.

O –Open-Closed Principle

The Open-Closed Principle, while made popular by Robert Martin was originally defined in 1988 by Bertrand Meyer. Meyer’s Open-Closed Principle states that once completed the implementation of a class could only be modified to correct errors, new or enhance features would require a new class to be created.

Robert Martin and others redefined this to refer to interfaces. Interface specifications can be re-used through inheritance but the implementation need not be. The existing interface is closed to modifications and new implementations must, at a minimum implement that interface.

L – Liskov Substitution Principle

The Liskov Substitution Principle, original introduced in 1987 by Barbara Liskov states that “in a computer program, if S is a subtype of T, then objects of type T may be replaced (substituted) by objects of type S without altering any of the properties of the program.

The most often cited example of classes which violate the Liskov Substitution principle is that of a Square and Rectangle.  In OO (Object-Oriented) development we would be happy to define a Rectangle as a base class and Square as a subtype of Rectangle.  A Square has four sides, all the angles are 900.  

However, a Square requires all sides to be equal.  This poses a problem when managing the height and width properties.  A Rectangle can have its height and width set separately - it would have two separate setters.  If the Square object subtypes Rectangle then in order to keep the height and width the same the setters would need to be modified so that setting the width would also set the height.  Thus a Square could not be substituted for a Rectangle in a computer program without altering the properties of the program.

I – Interface Segregation Principle

The Interface Segregation Principle encourages the use of smaller and more-specific Interfaces.  Larger interfaces often require clients to implement pieces that they will never use.

The example cited by Robert Martin to describe the benefits of this principle is the ATM usage case.  In designing an ATM the design must support a Braille UI, a Speech UI and a Screen UI.  This would normally be done by implementing an abstract ATM UI base class (or interface).  A better design which follows the Interface Segregation principle would be to split the abstract base class into three (or more) interfaces - a Deposit UI, a Withdrawal UI and a Transfer UI - i.e. a separate thin interface for each action that needs to be implemented.

D – Dependency Inversion Principle

One of the problems with the Interface Segregation principle is that now we have components with lots of dependencies that could be highly coupled.  The Dependency Inversion Principle states that high level modules should not depend on low level modules - both should depend on abstractions.  It also states that abstractions should not depend on details, details should depend on abstractions.

The goal is to decouple high-level components from low-level components such that reuse with different low-level component implementations becomes possible. This is facilitated by the separation of high-level components and low-level components into separate packages/libraries, where interfaces defining the behavior/services required by the high-level component are owned by, and exist within the high-level component's package.

Various patterns such as Plugin, Service Locator or Dependency Injection are then employed to facilitate the run-time provisioning of the chosen low-level component implementation to the high-level component.

This a very short summary of the SOLID Principles of Software design.  For readers wanting to delve deeper into the subject I highly recommend Robert Martin’s book “Agile Principles, Patterns and Practices in C#” published by Prentice-Hall.


Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Daniels (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out