In a previous article, S.O.L.I.D Principles are mentioned but offers no further explanation to what they are. Worry not, for this article aims to cover what they are and what makes them so wonderful.
S.O.L.I.D Principles are an acronym for a design pattern that is adopted in computer science. Whose aim is to make the development of software systems more readable, flexible and easier to maintain in the long run. While they apply to any object orientated language, they can also be heavily utilised in agile methodologies.
What are they?
Single responsibility principle
This principle states that every class or module should be responsible for one thing and that class should only hold function that relates to that task. This may sound silly and may sound like a lot of extra legwork, but the benefits of which are fantastic. Following this rule allows developers to be much tighter with the logic that they write. Take the following as an example;
The following code violates this principle as it contains logic to format a report. This is logic that can be abstracted out into another class that will solely deal with formatting.
For example, the following image displays the correct way to follow this principle;
While the above requires extra classes and logic, it allows a developer to write reusable code that is much cleaner and easier to understand, in turn, this makes it easier when it comes to writing unit tests.
Open/closed principle
Objects or entities should be open for extension but closed for modification. This essentially boils down to the point that logic can be built upon in a way that it will not break existing code. The following code example demonstrates code that does not follow the open/closed principle;
The best way to work around spaghetti code like this is to work in a way that leverages interfaces. This allows developers to program to those available methods, meaning that future code can be built upon by extending the interface that it implements. The following code snippet demonstrates a way to have extensible functionality.
Liskov substitution principle
Liskov states “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”. Which in layman’s terms means a subclass should override the parent class’ methods in a way that does not break functionality from a client’s point of view.
Interface segregation principle
The interface segregation principle states that no client should be forced to depend on methods that it does not use. This way of working splits large interfaces that aren’t very succinct, into much smaller, manageable interfaces. This approach aims to segregate logic into a decoupled approach that allows for ease of refactoring in the future. Take the following snippet for example. It strictly defines the methods that are available but takes no care for the logic that is contained within that method. This approach allows developers to write succinct and easy to follow code solutions.
Dependency inversion principle
The dependency inversion principle refers to the specific approach of decoupling software modules. When following this approach, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed. Thus rendering high-level modules independent of the low-level module implementation details. This approach is fantastic due to the fact that it allows decoupling of logic that much easier. Logic can be built inside of stand-alone classes or modules and can then be passed to along to other classes to utilise reusable code easily.
Benefits
Who doesn’t love clean code? This approach will lead to cleaner, more manageable code that can be easily unit tested, which in turn can allow for rapid development as it allows a more methodical approach. Strictly enforcing these rules will greatly benefit any project and should be heavily considered along with other agile methodologies.
Drawbacks
While S.O.L.I.D Principles have many benefits, there are also some drawbacks that need to be considered when trying to utilise this approach. It may make life easier for developers if it is included from the outset of a project. But trying to bend existing projects to fit this approach could potentially be near impossible.
Conclusion
This approach may not be for everyone and if your codebase does not currently follow S.O.L.I.D Principles, it may be very difficult to start adopting this approach. However, it may be worth adopting the dependency inversion principle, as it is the simplest approach to start with, but can greatly benefit a system. For more information about S.O.L.I.D Principles and how they could benefit you, don’t hesitate to contact one of our I.T. experts and they would be happy to provide more information, alternatively, you can visit our Web Design page or our Bespoke Database Development page for more information.
