Hi and welcome to the Pakainfo Engineering Tech Talks show I'm sure you've all heard about Solid principles for so many times but it's not always clear what they mean right?
my name is Jaydeep and I'ma software developer at Pakainfo and today I'm going to show you those principles with a bunch of simple examples I'm sure you can all understand those five simple principles were originally written by Robert Martin and since then they've helped a lot of developers to become a much better object-oriented programmers.
SOLID stands for:
SOLID is an important information of object oriented programming languages. The 5 principles are below.
- S - Single-responsiblity principle
- O - Open-closed principle
- L - Liskov substitution principle
- I - Interface segregation principle
- D - Dependency Inversion Principle
the first solid principle is single responsibility principle a class should have only one reason to change a class is what a class does the more class does the more likely it will be changed the more class changes the more likely it will introduce bugs this is why we need to keep in mind that the class should have only one responsibility this code was absolutely fine until the day.
I wanted to add rights to the shape I want that right method to write the shape into a file now our shape is doing two entirely separate things drawing and writing when the later changes all the class was compromised despite the fact the drawing was the same the solution is to make drawing and writing two separate classes thanks to this separation it will be easy to change shape whether writing or drawing logic needs to be changed.
the second solid principle is open closed principle software entities should be open for extension and closed for reduction it means that fresh behaviour comes with fresh source code not by updating the old code one back to my example.
let's take a look on how writer is implemented what if I would like to change the library I used to write with whatever life to print to the screen instead of writing to a file in either of those options concrete implementation details of writer would have to change so how do we achieve it rely on abstractions whether it's full abstraction like interface or partial obstruction like abstract file the solution would be to abstract writer.
here we can see that interface writer with two different data the permutations remember obstructions are always better than referencing concrete classes.
Liskov substitution principle
the third solid principle is Liskov substitution principle sub types must be substitutable for their base types well basically it means that if you want to replace a class with a subhead class the behaviour should stay the same let's go back to our example here we have rectangle that has two properties width and height and also one method called calc area now for this square although a square is a rectangle.
it has some different behaviour Square has the same value for width and height take a look at the test here do you see what's wrong although the client expected to get 18 he gets nine and this is exactly Liskovsubstitution violation square and rectangle are not substitutable a proper solution will be that both square and rectangle would implement interface shape.
here shape has only calc area and it won't hold any size properties like width and height then the square could have only one property.
Interface segregation principle
the fourth solid principle is interface aggregation principle classes that implement interfaces should not be forced to implement methods they do not use another way to say it use small interfaces not fat ones let's illustrate it suppose shape has all of these different abilities colour move rotate and suppose not all shapes have them clients should not be forced to depend upon interfaces that they do not use instead of creating a shape and throwing an exception when it doesn't have the specific ability we just need to separate all these abilities into separated interfaces we can easily compose the right behaviour for each shape with composing those interfaces together.
Dependency Inversion principle
the fifth and last principle is dependency inversion principle high-level modules should depend on abstractions and not on details now back to our example remember writer writer was dependent on how we write into a file in Java the solution was to abstract out writer and separate it from the specific logic.
You can visit my Article with More Examples : click here