Introduction to SOLID Principles

Many design patterns were developed with SOLID principles in mind. Therefore, it’ll be hard to learn design patterns unless we know SOLID principles. This is why the first part of the course will explain what these principles are and we’ll look at some examples of their implementation in C#.

But SOLID principles aren’t merely tools to help us learn design patterns. Every software developer who uses object-oriented programming languages needs to be familiar with SOLID principles and know how to apply them in their daily job. Being familiar with these principles will make us more effective in our jobs, which will help us progress in our careers. However, another thing to remember is that questions about SOLID principles are often asked during technical interviews. So, if we don’t know how to apply them, it might prevent us from getting the job we want.

The SOLID backbone of design patterns

For those who aren’t familiar with what these principles are, SOLID is an abbreviation that stands for the following:

• Single responsibility principle
• Open-closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle

Do we always need to use SOLID principles? Maybe not. After all, principles are not laws. There might be some exceptions where our code would actually be more readable or maintainable if we don’t apply them. To understand whether or not it makes sense to apply or not apply them in any given situation, we first need to understand them. This is what this part of this course will help us with.

But the important part is that we’ll struggle to fully understand design patterns unless we understand SOLID principles. SOLID principles are our foundation. Unlike design patterns, they don’t apply to any specific type of software development problem. They’re fundamental components of clean code. This is why we’ll start with SOLID principles.