This content originally appeared on DEV Community and was authored by Albert Bennett
If you learned something new feel free to connect with me on linkedin or follow me on dev.to :)
I feel like this is a topic that I don't see many people talking about so much anymore, so this is my explanation of it.
SOILD is an acronym for 5 core principals. These are a set of principals designed to make your code more maintainable and robust when, coding in an object orientated language. They stand for:
- Single Responsibility
- Open/ Close
- Liskov Substitution
- Interface Segregation
- Dependency Inversion (injection)
Brace yourself! There is a lot to go through...
Single Responsibility:
Essentially your method/ class should have one thing to do and do it well. For example, this is bad coding:
It's bad because, it doesn't make much sense to be writing an arbitrary piece of text to the console inside of a method called "Count". It's unexpected and unnecessary behavior. This on the other hand, is good. It's good because, each method now has a specific job.
Having an object only do one thing makes the code much easier to read and understand. Also, if it needs to be extended this can be done much more quickly.
Open/ Close:
Simply put, software entities (methods, classes, etc) should be open to extension and closed to modification. Hmmmm... time for another example, I think! In the code below we are trying to give the method too much functionality. In doing so we are modifying the expected behavior of the method. As you can see to modify something like this could become very trouble some.
Now consider this. We split up the class, add an interface and have each object specify how to handle the processing of an order. Now, we have something that is far more open to extension.
As you can see by adding a layer of inheritance we have not changed the underlying behavior of our interface and yet we have opened it up for extension. Now to follow the above example you'd need to add an if statement in the calling class for both object and switch between them. But you get the point, by abstracting the functionality out we have made the code much more flexible, including derived classes being able to implement the function in the interface in whichever way that they want to.
Liskov Substitution:
Basically, what this principal means is that a software entity should be replaceable with a sub-type without creating any new errors. Sub-type in this context means something that inherits from something else. Such as Order to IOrder. I feel another example coming up:
In the above sample we are violating the rule because, we should be able to use the BigOrder object in the same way as the Order object and well... right now we can't. Both objects are concreate implementations, of separate objects ie, they don't have a common sub-type. This can be problematic in the real world, especially when testing components of your software. A better way of doing the exact same thing is either, create a new method to take in the BigOrder object (this is bad don't do it) or require an interface instead.
In the above sample you can clearly see that the two implementations of IOrder (both BigOrder and Order inherit form IOrder) can be substituted with one another without effecting the functionality of the program.
Interface Segregation:
What this means is don't tack on new methods to an interface if they are unnecessary. Example, this is bad:
Now clearly a car shouldn't have any need for a fly function at least not in 2021 maybe 2030 though... Likewise a plane shouldn't be able to drive. As such we have introduced redundant functionality to both objects. Which violates this principal. We can fix this by introducing new interfaces to better manage the new functionality.
Simple when you see it in action.
Dependency Inversion (injection):
Finally, the great DI (Dependency Inversion (Injection)). This can be a massive topic in itself. And there are many ways of achieving this. The way I like to think of it is don't use the "new" keyword. except or at the composition route of your application. This principal states that:
- High/ low level modules should depend on abstractions
- Abstractions should not depend on details
Essentially don't depend on concrete implementations in your code. A concrete implementation is an instance or an object that was created using the 'new' keyword. If you have read down as far as here. First of well done, secondly you would have seen DI being used in some of the samples. From the sample below you can see the rule being violated because, in BuildHouse method we are using the new keyword to create an instance of the BrickLayer object. This added dependency reduces the test-ability of our method.
Now first off what we should do is to inject the BrickLayer into the BuildHouse method. However we can go one step further by abstracting the BrickLayer.
Great we did it! Now for the proof.
Super. Now if we needed to put in a dummy IConstructionWorker object into the method to test it. We can and without any issues.
I hope my explanation helps with your understanding of SOLID principals. See you next time.
This content originally appeared on DEV Community and was authored by Albert Bennett
Albert Bennett | Sciencx (2021-09-17T13:19:59+00:00) SOLID Principals for OOP. Retrieved from https://www.scien.cx/2021/09/17/solid-principals-for-oop/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.