DRY: Difference between revisions
Jump to navigation
Jump to search
| Line 13: | Line 13: | ||
=DRY and Coupling= | =DRY and Coupling= | ||
{{Internal|Designing_Modular_Systems#DRY_and_Coupling|DRY and Coupling}} | {{Internal|Designing_Modular_Systems#DRY_and_Coupling|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. | |||
=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:12, 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.
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/