Don't repeat yourself: Difference between revisions

From Cibernética Americana
Jump to navigationJump to search
(Created page with '{{TOCleft}} == Dominion Draft == Purpose: future reference, same as Class Enemy. == English Lede == '''Don't Repeat Yourself''' (or '''DRY''', also known as '''Single Poin...')
 
No edit summary
 
Line 1: Line 1:
{{TOCleft}}
{{TOCleft}}
[[:en:Don't repeat yourself|Current English Text]]
== Dominion Draft ==
== Dominion Draft ==



Latest revision as of 10:24, 22 February 2010

Current English Text

Dominion Draft

Purpose: future reference, same as Class Enemy.

English Lede

Don't Repeat Yourself (or DRY, also known as Single Point of Truth and Single Point of Maintenance) is a process philosophy aimed at reducing repetition, 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.

Teaching DRY coding skills

The DRY code philosophy is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." This philosophy is also prevalent in model-driven architectures, in which software artifacts are derived from a central object model expressed in a form such as UML. DRY code is created by data transformation, which allows the software developer to avoid copy and paste operations. DRY code usually makes large software systems easier to maintain, as long as the data transformations are easy to create and maintain. Tools such as XDoclet and XSLT are examples of DRY coding techniques. Examples of systems that require duplicate information are Enterprise Java Beans version 2, which requires duplication not just in Java code but also in configuration files. Examples of systems that attempt to reduce duplicate information include the Ruby on Rails application development environment and Enterprise Java Beans version 3.

Data transformation skills are not taught in most basic-level software engineering courses. Current computer science curricula tend to be heavily weighted toward procedural skills such as Java, C++, or C#. The use of DRY code becomes increasingly important as developers create applications that use multi-tier architectures. The model-view-controller architectural pattern also challenges software developers to use data transformations. Developments in some language features, such as Java annotations, may allow additional metadata to be stored within object class definitions and accessed at run time, allowing features such as automatic view generation directly from models.

Once and Only Once

DRY is broader than Once and Only Once (OAOO). 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. DRY is not about just avoiding code duplication, but more generally about avoiding multiple and possibly diverging ways to express every piece of knowledge: e.g., logic, database schemas, and constants.

When DRY may not be advantageous

In some contexts, the effort required to enforce the DRY philosophy may be greater than the effort to maintain separate copies of the data. In some other contexts, duplicated information is immutable or kept under a control tight enough to make DRY not required.

  • Imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a wiki.Template:Fact
  • Configuration management and version control tools allow multiple and diverging copies ("branches"). For example, good practice generally involves development, testing, and production using different source code bases so that ongoing development and testing do not affect production. Ideally, divergence is temporary; differences are kept reasonably small and eventually reconciled ("merged") with the help of the tools.
  • 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 the effort should be made to generate it rather than write it.
  • Source code generation - Non-duplication could be useful for the source code generator, but not for the result, if the duplicate information is never modified.
  • Limitations of a programming language can sometimes make it to easier to duplicate code. For instance, the two functions addAll(myGraph) and multiplyAll(myGraph) duplicate the code to browse the same type of graph. The DRY principle recommends refactoring to applyAll(myGraph, add) and applyAll(myGraph, multiply). However, in languages with poor functional support, such a refactoring is likely to be costly to implement, and to produce verbose and confusing code.

See also

References

  1. Dave Thomas, interviewed by Bill Venners (2003-10-10). "Orthogonality and the DRY Principle". Archived from the original. Error: You must specify the date the archive was made using the |archivedate= parameter. http://www.artima.com/intv/dry.html. Retrieved on 2006-12-01. 

External links

es:No te repitas fr:Ne vous répétez pas it:Don't Repeat Yourself ja:Don't repeat yourself pl:DRY ta:திருப்பி ஒன்றைச் செய்யாதே