Solid Principles in C# - Introduction

It's time to talk about a topic that every developer should know to work better regardless of the language or framework used: The S.O.L.I.D principles.

What are the S.O.L.I.D. principles?

The S.O.L.I.D. design principles are a collection of best practices for object-oriented design. The term S.O.L.I.D. comes from the initial letter of each of the five principles that were collected in the book Agile Principles, Patterns, and Practices in C# by Robert C. Martin, or Uncle Bob to his friends.

It was written in 2000, 20 years ago since this article was published. But these Principles are still popular and are still being used widely in the world of OOP Paradigm. You can find the original pdf here https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

Yes, you’re not reading it wrongly nor I have a typo. It was written in 2000, 20 years ago since this article was published. But these Principles are still quite popular and are still being used widely in the world of OOP Paradigm.

Why should you use the S.O.L.I.D. principles?

Short answer: Software Rot or Code Rot or Software Erosion is either a slow deterioration of software quality over time or its decreasing responsiveness, which will eventually lead to software becoming faulty, unusable, and in need of upgrade.

Long answer: Software rot refers to the slow degradation in the performance of computer software. Such software shows diminished responsiveness, lacks updates, may become faulty overtime owing to changes in the operating system it is running on and thus may need upgrading.

These are some signs for identifying Software Rot:

• Rigidity: Difficult to modify the code. New requirements or small changes leads to rebuild the entire software.
• Fragility: New modifications introduce bugs and vulnerability in the code.
• Immobility: Non-portability of the code. if a component/module/function cannot be used in another system, this is considered as immobile.
• Viscosity: When implementing and testing are difficult to perform and also take a long time to execute.
• Changing Requirements or Changing Needs: Often changes need to be made quickly and may be made by engineers who are not familiar with the code. We cannot dodge the new requirements but we must somehow find a way to make our designs/project resilient to such changes and protect them from rotting.
• Dependency Management: We know changes introduce new and unplanned for dependencies, so inappropriate module dependencies and increased coupling between systems make the source code more difficult to manage. In order to prevent the degradation of the dependency architecture, the dependencies between modules in an application must be managed.

What will you achieve by using the S.O.L.I.D. Principles?

• Code More Maintainable. Using the Single Responsibility Principle (SRP) and the Open closed principle (OCP) you will be easier in maintaining your code.
• Code More Flexible. It’s quite easy when you need to add features in your code because all codes are loosely coupled.
• Code More Understandable. When you come back to your code six months later, you still understand what you wrote back then.

So what are you waiting for? Try opening your own old project and start applying the principles. You will only see improvements.

(S) Single Responsibility Principle - SRP

The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change.

(O) Open closed principle - OCP

The Open closed principle (OCP) states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

(L) Liskov substitution principle - LSP

The Liskov substitution principle - (LSP) states that objects of a superclass shall be replaceable with objects of its subclasses without breaking the application.

(I) Interface segregation principle - ISP

The Interface segregation principle - (ISP) states that no client should be forced to depend on methods it does not use

(D) Dependency inversion principle - DIP

The Dependency inversion principle - (DIP) introduces an abstraction that decouples the high-level and low-level modules from each other.

If you think your friends/network would find this useful, please share it with them. I’d really appreciate it.

Thanks for reading!

Feel free to explore more of my articles on my blog www.ottorinobruni.com for additional insights. Your feedback and comments are always welcome!