DRY: Difference between revisions
| Line 14: | Line 14: | ||
{{Internal|Designing_Modular_Systems#DRY_and_Coupling|DRY and Coupling}} | {{Internal|Designing_Modular_Systems#DRY_and_Coupling|DRY and Coupling}} | ||
=Duplication Considered Useful= | =Duplication Considered Useful= | ||
The DRY principle discourages duplicating the implementation of a concept, which is not the same as duplicating literal lines of code. Having multiple components depend on shared code can create tight coupling, making it hard to change. | The DRY principle discourages duplicating the implementation of a concept, which is not the same as duplicating literal lines of code. Having multiple components depend on shared code can create tight coupling, making it hard to change. Also, use of shared (DRY) code between a client and a server can create tight coupling. More generically, if shared code leaks outside the component boundary, this leads to coupling. As an example, a library of common domain objects that represent the core entities in a system and that is used by all the microservices in a system can cause to have to update all services if a change is made to it. If the services communicate via messages, the message queues also have to be drained to flush out content based on the old domain model, now invalid. | ||
=Organizatorium= | =Organizatorium= | ||
* The "rule of three" for software reuse suggests the you should turn something into a reusable component when you find three places that you need to use it. https://blog.codinghorror.com/the-delusion-of-reuse/ Facts and Fallacies of Software Engineering https://www.amazon.com/exec/obidos/ASIN/0321117425/ | * The "rule of three" for software reuse suggests the you should turn something into a reusable component when you find three places that you need to use it. https://blog.codinghorror.com/the-delusion-of-reuse/ Facts and Fallacies of Software Engineering https://www.amazon.com/exec/obidos/ASIN/0321117425/ | ||
Revision as of 22:14, 3 January 2022
External
- Pragmatic Programmer, The: From Journeyman to Master by Andrew Hunt and David Thomas
Internal
Overview
Don't Repeat Yourself (DRY) principle sys: "Every piece of knowledge should have a single, unambiguous, authoritative representation within a system."
If you are in the position to write the second time the same behavior (copy-and-paste) that means the behavior belongs into a reusable function. Duplication forces people to make a change in multiple places, and that is not good.
DRY and Coupling
Duplication Considered Useful
The DRY principle discourages duplicating the implementation of a concept, which is not the same as duplicating literal lines of code. Having multiple components depend on shared code can create tight coupling, making it hard to change. Also, use of shared (DRY) code between a client and a server can create tight coupling. More generically, if shared code leaks outside the component boundary, this leads to coupling. As an example, a library of common domain objects that represent the core entities in a system and that is used by all the microservices in a system can cause to have to update all services if a change is made to it. If the services communicate via messages, the message queues also have to be drained to flush out content based on the old domain model, now invalid.
Organizatorium
- The "rule of three" for software reuse suggests the you should turn something into a reusable component when you find three places that you need to use it. https://blog.codinghorror.com/the-delusion-of-reuse/ Facts and Fallacies of Software Engineering https://www.amazon.com/exec/obidos/ASIN/0321117425/