We will now dive deep into one of the most exciting parts of clean code in C, sharp or clean code in
general, which are the solid principles.
So solid are five principles for clean code.
They make your code easier to understand, more flexible and maintainable.
So solid consists out of five characters, right S, O, L, I, and D.
And for every letter we have one principle.
Let's start with the s, which is the single responsibility principle.
Again, one sentence and we will dive deep into in this section into every of those five principles.
Right.
Single responsibility principle.
This one keeps your code encapsulated and easy to maintain, because every class has one responsibility
and you just compose them together, right?
So if you need that functionality and this functionality and that, then you just bring them together.
That's the cool part about it.
Then we get to the O, which is the open closed principle that basically means, in easy words, that
when you have some code that works fine and you want to add a new feature and you want to extend that
code, then you just create derived versions from that, you add interfaces or whatever, but you do
not change the working code base, right?
Because that one is already working.
If you want to add some additional functionality, you want to make use of inheritance interfaces and
so on.
So we are open for extension, but we are closed for modification on the existing code.
That's the O.
So open closed.
Then we get to the Liskov substitution principle which sounds more complicated to be honest than it
really is.
It just says that if you have a base class, right, and you would derive two classes from that or one
class, you should be able to still use that base class, then create an instance from that derived
class.
And that should not break the program or cause any errors.
You will see this with a very handy example, right?
Let's move on to the I, which is the interface segregation principle that one simply says that if you
have bloated interfaces which offer tons of functionality, but your classes are not using all of those
methods that you have inside of your interfaces, right, then you should break down that one bloated
interface into smaller interfaces, and then you let just your classes implement whatever functionality
they need.
So basically, think of it like you have a big interface and you split it down.
And the last one is the the dependency inversion principle.
And here we're just talking about that we should not couple high level modules with low level modules.
Again we will dive deep here with an example.
All right.
So without further talking let's get started with the first principle which is the single responsibility
principle or in short SRP.