DRY Principle

Dont Repeat Yourself

This is one of the principles of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using appropriate data normalization to avoid redundancy.

"Every piece of knowledge"

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

By the term Every piece of knowledge may be an algorithm, some specific functional logic, a pattern of similar code snippets with similar business logic which could have been repeated at a number of places across your solution. This causes maintainability of the solution difficult, while bringing consistency and synchronisation among different aspects of the application time consuming, when more and more repeatable blocks of the same aspect is scattered across your solution.

By following DRY it is expected that these repeatable modules can be abstracted and used across various other modules, so that you need it not repeat it and it could be reused efficiently. At the same time, when you have the opportunity to refine this abstraction you can refine it at one place, so that it happens to be consistent across your solution.

An abstraction is a general idea rather than one relating to a particular object, person, or situation

Premature Abstraction

You shouldnt apply the DRY principle if your business logic doesnt have any duplication yet. As a rule of thumb, trying to apply DRY to something which is only used in one place can lead to premature generalisation.

You will spend time to create abstractions which might be only used in one place, for a very long time. Requirements can change very quickly like today, everybody will tell you that you need some generalisation for the future reuse, and tomorrow, everybody will forget about it.

Eventually you have introduced more complexity and tight coupling in your code for no short term benefits.

Code duplication is not knowledge duplication

Duplication is far cheaper than the wrong abstraction.

Code duplication is different from knowledge duplication, since code duplication, largely related to the developers and it could be more attributed to readability and clarity of the module they are working on. But functional business logic is what we called here as piece of knowledge, which should be accounted for in DRY principle.

• Knowledge duplication can be taken as DRY principle violation.
• Code duplication need not necessarily violate the DRY principle.

Applications of DRY

DRY could be applied quite broadly in the various areas of software development like the below listed.

• database schemas
• test plans
• the build systems
• and also documentations

DRY Benefits

• every piece of code is unique
• less code is good
• easy to maintain
• reduces the chances of bugs.

Trade-offs

While you apply DRY principle, you could have made your code easier to understand, but the scope of your changes would become wider. if there is any significant change in underlying contract, you may have to make sure every other integrations are fine with it.

In short, trying to apply DRY everywhere can also yield two undesirable results while creating these abstractions.

• Unnecessary coupling
• Unnecessary complexity

In these situations, the cost of involved in the either side for maintainability should be weighted before taking a call on going for further abstractions.

Tools not Rules

Again with any other principle, they are not to be considered as rules you should follow. But these are great tools for you to go in the right path in software engineering. Its your job to adapt them depending on the requirement you may encounter.

reposted from Dev Post