SOLID principles in Real World

S.O.L.I.D

This abbreviation supposed to give you an opportunity to keep in mind 5  main design principles,that you have to use while writing your App  classes.

• Single Responsibility Principle (SRP).
• Open/Closed Principle (OCP). 
• Liskov's Substitution Principle (LSP).
• Interface Segregation Principle (ISP).
• Dependency Inversion Principle (DIP).

---- ## Single Responsibility Principle _(SRP)_ > _"One class should have one and only one responsibility!"_ Another-words, there should be no more than one reason to change the class or method. It's important to separate each responsibility to the separate class, because each one is the axis of changes. So, it's about actors and high level architecture. Whenever you observe that class or module start to change for different reasons, don't be shy to respect SRP. If u want to try to follow this principle from early beginning, then try to understand what actors and for which purposes will use your class. If the needs of the actors are not the same, then it's obvious that u should separate responsibilities into the different classes to not violate SRP principle. Example: Assume that u have a `Book` with `getPage()` and `print()` methods. Sounds logically but it against SRP principle. Thing about the actors that will use your `Book` class. Let it be some `Library`, that will manage `Book` instances, by title, by author, etc. and from another side it can be some `UI` or `Graphic` view that display some page or the `Book` itself. So here we explicitly can see the two totally different axis of changes. The way to respect SRP in this situation can be an extraction of the `print()` method logic to the separate class `Printer` with the `print(IPrintable page)` method, which can print any received page from any other entity. So if u'll need to modify the print options it won't affect your `Book` class at all. ---- ## Open-Closed Principle _(OCP)_ > _"Software entities should be opened for extension, but closed for modification."_ It means, that your system should be flexible and be able to adopt to the changing conditions by extension of an existing code, but without base logic modification. So, it's about the class design and feature extension. For example: if u will take some good frameworks, u will see that u're are able to change their core logic flow via extending and overriding some entities, but with no framework modification. To be more specific: assume that u have a `Book` and a `Logic`. So, if the `Book` is directly used by `Logic` it violates OCP, because if u'll need some another `Logic` or some `Vocabulary` instead of `Book` it will require changes in the existing `Logic` or usually in both: in the existing `Logic` and in the `Book`. So, the most common solution to respect OCP is using of the `Strategy Pattern` or the `Template Method Pattern`_(In more specific applications)_. Solution for the case with `Book` can be the following: The `Logic` can use some interface `IReadable` which is implemented be the `Book` and by the `Vocabulary`, `Dictionary`, etc. as well. So, it won't be necessary to modify your `Book` class or `Logic` if u need to add some `Catalog`. ---- ## Liskov's Substitution Principle _(LSP)_ > _"Objects should be replaceable with instances of their sub-types with no altering the program correctness."_ If `S` is a subtype of `T`, then objects of type `T` may be replaced with objects of type `S` without altering any any part of base code. Another-words, derived class or subclass mast enhance functionality, but not reduce them. As simple as that, a subclass should override the parent class' methods in a way that does not break functionality from a client's point of view. So, it's about sub-typing and inheritance. The most simplest example of LSP violation is a story about the `Rectangle` & `Square`. Assume that u have a `Square` that extends a `Rectangle`. In real life, the `Square` is a particular form of `Rectangle`. But if u extend some object - you commit that you is that object and you behave in the same way as he. So, if there will be some `Logic` which interacts with the `Rectangle` and u will pass there your `Square`, it might cause an exception. Cause it's not possible to define `width` and `height` separately for the `Square`, but `Logic` assumes that it's possible, because your `Square` commits that it's a `Rectangle`. ---- ## Interface Segregation Principle _(ISP)_ > _"Many client-specific are better than one general purpose interface."_ The clients should not be forced to implement unnecessary methods which they will not use. This happens mostly when an interface contains more than one functionality, but the client needs only one functionality and not another. So, it's about the business logic to clients communication. For example: if u have some `IWorker` interface that has `work()` and `eat()` function definitions. Definitely we have some `Worker` that implements `IWorker` and can work and eat. But not globalization affects the company and it's needed to add some `Robot` that has to work but it doesn't need to eat. So, we stuck because ISP was violated here. To respect ISP here, we can easily segregate `IWorker` into two interfaces e.g. `IWorkable` and `IFeedable`, but in real project such changes can affect a huge part of Logic - that's why it's much more better to design interfaces correctly. First of all we should thing about what the clients actually need and what will use. Often the clients may need and use the several interfaces. So, it's fine, while they use all methods from the interfaces they depend on. ---- ## Dependency Inversion Principle _(DIP)_ > _"Depend on abstraction not on concretion."_ In other words, you should design your software in the way to be able easily substitute/separate your modules from each other. So your modules should be related via abstractions and closed enough, that u'll able to use them apart from your application. **"Abstractions should not depend upon details. Details should depend upon abstractions."** In short u shouldn't create dependencies by yourself, but should receive them from somewhere. For example, if u have a `View` and a `Model`. U won't create a `Model` in your `View` _(i believe:))_, but will receive the reference on it from outside and it will be some interface `IModel` that will decouple your `View` from the `Model` implementation. This could be achieved via the more particular approach: `Dependency Injection` _(passing your dependencies via setters, arguments, or via using reflection)_. So, is the `Dependency Inversion` the same thing as `Dependency Injection` - No! `Dependency injection` is an approach supposed to respect `Inversion of Control` or `Dependency Inversion principle`. `Dependency injection` force u to provide some entry points to inject the dependencies into your class from outside, so it's just a particular implementation of `Dependency Inversion`. For example, your class can ask some depended entity from some registry, so it will respect DIP but it will not be `Dependency Injection`, cause dependency wasn't injected from outside, but was asked/gotten from outside. ---- ## Final Thoughts > _"Assume about how your code will be used, before it's creation."_ So, we just ensured, that all SOLID principles are complementary and if we respects some of them than it's more easy to respect the another one. As long as you will respect SOLID principles, you will be able decouple your modules functionality, reuse existing parts in different projects and make them better. U will able to migrate your application on different principles on different databases, etc. So, let's make your code more clear and flexible, and it will simplify your & teammates life. ---- ## see Also * [The Law of Demeter (LoD) flashback](http://bloomlab.blogspot.com.ee/2016/08/the-law-of-demeter-lod-flashback.html) * [The Liskov Substitution Principle (LSP) flashback](http://bloomlab.blogspot.com.ee/2016/12/liskov-substitution-principle-lsp.html) * [Fail-Fast instead of Fire-and-Forget](http://bloomlab.blogspot.com.ee/2015/11/fail-fast-instead-of-fire-and-forget.html) * [JavaDOC - Properties](https://docs.oracle.com/javase/7/docs/api/java/util/Properties.html)