Don't repeat yourself

From Wikipedia, the free encyclopedia

Contrast with redundancy and mirror.

Don't Repeat Yourself (DRY, also known as Single Point of Truth) is a process philosophy aimed at reducing duplication, particularly in computing. The philosophy emphasizes that information should not be duplicated, because duplication increases the difficulty of change, may decrease clarity, and leads to opportunities for inconsistency. DRY is a core principle of Andy Hunt and Dave Thomas's book The Pragmatic Programmer. They apply it quite broadly to include "database schemas, test plans, the build system, even documentation."[1] When the DRY principle is applied successfully, a modification of any single element of a system does not change other logically-unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync.

Contents

[edit] Once and Only Once

DRY is distinct from Once and Only Once (OAOO) in that DRY speaks to information needed by the application (usually configuration data). By comparison OAOO speaks to the functional behavior of the code and is the reason for object composition and the implementation of inheritance in object oriented languages. For example, while DRY says that the location of a collection of files should be stored only once within the application, it is agnostic to the number of times code for retrieving data from those files is written in different parts of the application. The principle of OAOO by comparison would demand that code for retrieving data from files be written only once, but is agnostic to the number of places where the location of those files is stored within the application. What may be even more confusing is that because an object may be stored as a variable within an application, that object may be viewed as a piece of information and so DRY may apply also to the object (having only one instance) while OAOO applies to the class (having no other code within the application which has the same purpose as code within the object's class template).

[edit] When DRY may not be advantageous

  • In some small-scale contexts, the effort required to design around DRY may be far greater than the effort to maintain two separate copies of the data.
  • Imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a wiki.
  • Configuration management and version control allow multiple working copies of the same code without setting aside DRY. For example, good practice generally involves setting up development, testing, and production environments so that ongoing development and testing do not affect production code.
  • Human-readable documentation (from code comments to printed manuals) are typically a restatement of something in the code with elaboration and explanation for those who do not have the ability or time to read and internalize the code. However, DRY holds that if the human-readable document adds no value except the change in format, then it should be generated rather than written.
  • Source code generation - Non-duplication could be useful for the source code generator, but not for the result, if the duplicate information there will never be changed by humans or other code.

[edit] See also

[edit] References

  1. ^ Dave Thomas, interviewed by Bill Venners (2003-10-10). Orthogonality and the DRY Principle. Retrieved on 2006-12-01.

[edit] External links