Writing code in C# is relatively easy as compared to other languages available. C#, being an object-oriented language, uses all the object-oriented features we discussed in my post (OOPS concepts ), such as encapsulation, classes, inheritance, interfaces, and polymorphism. However, these features by themselves don’t guarantee that your code is written in the right way. It is not at all uncommon for a beginner to use these features in a wrong or unintended way. For example, by creating a class with a lot of methods and properties that should not have been part of that class at all, or by using inheritance hierarchies in the wrong way. In an object-oriented system, identifying classes and objects and deciding how they interact with each other can become complex depending on the given business problem. Moreover, your design needs to be flexible enough so that future extensions are easy. Wouldn’t it be great if you knew of some standards or guidelines that you could keep in mind while writing C# code? That’s what SOLID principles are!
In their book Agile Principles, Patterns, and Practices in C#, Robert C. Martin and Micah Martin . Martin and Micah Martin elaborate on five principles of object-oriented software design. These principles are named as follows:
Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
Michael Feathers introduced an acronym—SOLID—to help us remember these principles easily. As you can see, the first letter of each of these principles makes the word SOLID, and hence collectively they are referred as SOLID principles.
These principles form the fundamental guidelines for building object-oriented applications. Following these principles while writing C# code will help you to build a robust, extensible, and maintainable code base. Moreover, these principles also form a vocabulary with which to convey the underlying ideas between other team members or as a part of technical documentation.
In the following paragraphs I will give a brief overview of each of these principles.
SINGLE RESPONSIBILITY PRINCIPLE (SRP):
Single Responsibility Principle (SRP ) suggests that a class should have one and only one responsibility. A class is like container. One can add any amount of data, properties, and methods into it. However, if you try to achieve too much through a single class, soon that class will become bulky. Any small change you need will result in your changing this single class. And since you changed the class, you will also need to test it again. If you follow SRP, your classes will become compact and neat—each is responsible for a single problem, task, or concern. This way a change in the system requires a change in the corresponding class, and only that class needs to be tested again. SRP is a way to divide the whole problem into small parts, and each part will be dealt with by a separate class.
Note
You may come across another principle of object-oriented design, Separation of Concerns (SoC), that conveys a similar idea.
OPEN/CLOSED PRINCIPLE (OCP):
Open/Closed Principle (OCP) states that a class should be open for extension and closed for modifications. This means that once you create a class and other parts of the application start using it, you should not change it. Why? Because if you change the class, it is quite possible that your changes may cause the otherwise working system to break. If you require some additional features, you should extend that class rather than modifying it. This way the existing system won’t see any impact from the new changes. Also, you need to test only the newly created class.
LISKOV SUBSTITUTION PRINCIPLE (LSP):
Liskov Substitution Principle (LSP ) states that derived classes should be substitutable for their base classes. When you create a class that inherits from some other class, you are free to add new features into the derived class. They may even work without any problem as long as you use the derived class on its own. However, when you resort to polymorphic behavior through inheritance, the derived class, if not following LSP, can pose problems in the system. That’s because you are now using it in a place where the base class was expected.
INTERFACE SEGREGATION PRINCIPLE (ISP):
Interface Segregation Principle, or ISP , states that clients of your classes should not be forced to depend on methods they do not use. Think of a class that has ten methods—five are needed by desktop clients and five are needed by mobile clients. Thus, the same interface consisting of ten methods is being used by both desktop and mobile clients. Now, tomorrow if a method required by a desktop client changes, you will need to update both versions of your application, because even the mobile client is dependent on the same interface, even though it is not using the changed method. This is unnecessary, and ISP suggests you avoid such situations. So, as per ISP, you would have to create two separate interfaces—one containing the five methods required by the desktop client and the other consisting of the remaining five required by the mobile client.
DEPENDENCY INVERSION PRINCIPLE (DIP):
Dependency Inversion Principle, or DIP , states that high-level concrete classes should not be dependent on other low-level concrete classes. Instead, they should depend on abstract classes or interfaces. This simply means that you should not use concrete low-level classes inside a high-level class, because then the high-level class becomes tightly coupled with those low-level classes. Tomorrow if any of the low-level classes change, the high-level class may break. As per DIP, the high-level classes should depend on abstraction (in the form of abstract classes or interfaces) and so should the low-level classes. The tight coupling is removed by coding both levels of classes against interfaces.