DRY: Difference between revisions
| Line 13: | Line 13: | ||
=Duplication Considered Useful - DRY and Coupling= | =Duplication Considered Useful - DRY and Coupling= | ||
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. | 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. | ||
When considering whether code is duplicated and should be centralized, consider whether the code truly represents the same concept. Does changing one instance of the code always mean the other instance should change as well? | |||
Reuse increase coupling. | |||
=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:18, 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.
Duplication Considered Useful - DRY and Coupling
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.
When considering whether code is duplicated and should be centralized, consider whether the code truly represents the same concept. Does changing one instance of the code always mean the other instance should change as well?
Reuse increase coupling.
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/