Introduction
As a software developer, you are undoubtedly familiar with the importance of writing clean, maintainable code. There are several principles and best practices that can help you achieve this goal, including Single Source of Truth (SSOT), Don't Repeat Yourself (DRY), and Single Responsibility Principle (SRP). This post briefly covers each of these principles and how they can help you write maintainable code.
SSOT
Single Source of Truth (SSOT) is a design principle that aims to ensure that data in a system is stored in a single location rather than being duplicated or scattered throughout your codebase. This principle focuses on the data inside a system and using references to other data instead of making copies of data and storing it elsewhere.
DRY
Don't Repeat Yourself (DRY) is a principle that encourages developers to avoid duplication of knowledge in a system. What is knowledge? Knowledge can be an algorithm or a business process inside your code. The idea behind dry is not to copy that knowledge every time you need it. But to solve it in a more maintainable way, like creating an abstraction or using references to that code.
The downside of copy-pasting algorithms or processes in your code is that if the algorithm has to change, you need to find and change it everywhere you copy-pasted it; this could be a lot and is prone to errors.
SRP
The single Responsibility Principle (SRP) is part of SOLID and is a software design principle that states that a given class or module should have only one reason to change. In other words, a class or module should have a single, well-defined responsibility and not be responsible for multiple, unrelated tasks.
SRP example
Imagine you write an algorithm for department A in your company to help them calculate the right amount of TAX for a product. A few weeks later, department B wants the same functionality. You write some (boilerplate) code and make a call to the same algorithm.
A few days later, department B wants to change this algorithm to add one dollar to the end result. You make the change, and everything seems great. Now department A is using an algorithm which gives them a bad result. By making this algorithm responsible for two departments, you break SRP.
To prevent this from happening, it would be better to make an abstraction of the algorithm or make a copy, one for each department.
Conclusion
While these principles seem similar at first glance, they are quite distinct and serve different purposes. SSOT ensures that data is stored in a single location, while DRY eliminates duplicate code. On the other hand, SRP is concerned with the responsibilities of individual classes and code.
By applying these principles, you write code that is simpler, more reliable, and easier to maintain.
