The S.O.L.I.D. Principles

There have been many questions I encountered lately of what are the best practices / guidances that you can take up on when designing an application.

Wheather that’s an ASP.NET application or any other type of application that uses object oriented principles.

First and upmost, let me begin with probably one of the most important principles in object-oriented development and design, and that is the Separation of Concerns(SoC) principle.

Separation of Concerns (SoC)

SoC is the process of dissecting a piece of software into distinct features that
encapsulate unique behavior and data that can be used by other classes. Generally, a concern represents a feature or behavior of a class. The act of separating a program into discrete responsibilities significantly increases code reuse, maintenance, and testability. Like, for example MVC can separate content from presentation and data-processing (model) from content.

Of course, every programming language has it’s own ways to incorporate this principle in it’s own ways.

The S.O.L.I.D. Design Principles

S.O.L.I.D. (stands for Single responsibility, Open-closed, Liskov substitution principle, Interface segregation and Dependency inversion).

The S.O.L.I.D. design principles are a collection of best practices for object-oriented design. All of the generally known Gang of Four design patterns adhere to these principles in one form or another. The term S.O.L.I.D. comes from the initial letter of each of the five principles that were first collected in the book Agile Principles, Patterns, and Practices in C# by Robert C. Martin. Commonly known to us as “Uncle Bob”

The following sections describes each one of them.

Single Responsibility Principle (SRP)

The principle of SRP is closely aligned with SoC(Separation of Concerns) principle which we discuss above. It states that every object should only have one reason to change and a single focus of responsibility. By adhering to this principle, you avoid the problem of monolithic class design that is the software equivalent of a Swiss army knife, meaning putting everything in a few or one class that does all the work for you. By having concise objects, you again increase the readability and maintenance of a system.

Open-Closed Principle (OCP)

The OCP states that classes should be open for extension and closed for
, in that you should be able to add new features and extend a class without changing its internal behavior. The principle strives to avoid breaking the existing class and other classes that depend on it, which would create a ripple effect of bugs and errors throughout your application.

Liskov Substitution Principle (LSP)

The LSP dictates that you should be able to use any derived class in place of a parent class and have it behave in the same manner without modification. This principle is in line with OCP in that it ensures that a derived class does not affect the behavior of a parent class, or, put another way, derived classes must be substitutable for their base classes.

Interface Segregation Principle (ISP)

The ISP is all about splitting the methods of a contract into groups of responsibility and assigning interfaces to these groups to prevent a client from needing to implement one
large interface and a host of methods that they do not use. The purpose behind this is so that classes wanting to use the same interfaces only need to implement a specific set of methods as opposed to a monolithic interface of methods. In other words the notion that “many client specific interfaces are better than one general purpose interface.”

Dependency Inversion Principle (DIP)

The DIP is all about isolating your classes from concrete implementations and having them depend on abstract classes or interfaces. It promotes the mantra of coding to an interface
rather than an implementation, which increases flexibility within a system by ensuring you are not tightly coupled to one implementation. This is heavily used in the new ASP.NET MVC pattern as Dependency Injection(DI) and Inversion of Control(IoC), where you would normally use the Repository pattern with it to “hide” the underlying data access and inject or fake different implementations when needed, but we’ll get to that in much more details in another post.

So, there it is, sort of a short overview of S.O.L.I.D. design principles. Of course, there’s much more to object-oriented design. Hopefully we’ll get into much more details in future posts.

You can find out much more if you take a look at Uncle Bob’s videos, and read his book Agile Priciples Patterns and Practices.

‘Till next time…..Taaaa daaaa….