Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Don't repeat yourself
open-in-new
<h2 id="single-choice-principle">Single choice principle</h2> <p>A particular case of DRY is the single choice principle. It was defined by <a href="/facts/Bertrand_Meyer/fHywGneP">Bertrand Meyer</a> as: "Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list."<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> It was applied when designing <a href="/facts/Eiffel_(programming_language)/gEzPjzmn">Eiffel</a>. </p> <h2 id="alternatives">Alternatives</h2> <h3>WET</h3> <p>The opposing view to DRY is called WET, a <a href="/facts/Backronym/LhorLRMH">backronym</a> commonly taken to stand for <i>write everything twice</i><a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> (alternatively <i>write every time</i>, <i>we enjoy typing</i> or <i>waste everyone's time</i>). WET solutions are common in multi-tiered architectures where a developer may be tasked with, for example, adding a comment field on a form in a web application. The text string "comment" might be repeated in the label, the HTML tag, in a read function name, a private variable, database DDL, queries, and so on. A DRY approach eliminates that redundancy by using frameworks that reduce or eliminate all those editing tasks except the most important ones, leaving the extensibility of adding new knowledge variables in one place.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a> This conceptualization of "WET" as an alternative to "DRY" programming has been around since at least 2002 in the Java world, though it is not known who coined the term.<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> </p> <h3>AHA</h3> <p>Another approach to abstractions is the AHA principle. AHA stands for <i>avoid hasty abstractions</i>, described by <a href="https://kentcdodds.com/blog/aha-programming">Kent C. Dodds</a> as optimizing for change first, and avoiding premature optimization.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> and was influenced by <a href="/facts/Sandi_Metz/mmlNxGFQ">Sandi Metz</a>'s "prefer duplication over the wrong abstraction".<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a> </p><p>AHA is rooted in the understanding that the deeper the investment engineers have made into abstracting a piece of software, the more they perceive that the cost of that investment can never be recovered (<a href="/facts/Sunk_cost/S0N2pv1C">sunk cost fallacy</a>). Thus, engineers tend to continue to iterate on the same abstraction each time the requirement changes. AHA programming assumes that both WET and DRY solutions inevitably create software that is rigid and difficult to maintain. Instead of starting with an abstraction, or abstracting at a specific number of duplications, software can be more flexible and robust if abstraction is done when it is needed, or, when the duplication itself has become the barrier and it is known how the abstraction needs to function. </p><p>AHA programming was originally named "moist code" by Dodds, later again by Daniel Bartholomae,<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a> and originally referred to as DAMP (<i>Don't Abstract Methods Prematurely</i>) by Matt Ryer.<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a> There was a different programming principle already named DAMP (<i>Descriptive And Meaningful Phrases</i>) and described by Jay Fields,<a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a> and the community pushed back against the usage of MOIST, due to the cultural aversion to the word <i>moist</i>.<a class="footnote-ref" id="fnref:12" href="#fn:12"><sup>12</sup></a> Dodds called for alternatives on <a href="/facts/Twitter/VWwDNGUm">Twitter</a>, and suggested DATE as an alternative before settling on <a href="/facts/Cher_Scarlett/oERe5AxC">Cher Scarlett</a>'s suggestion of AHA.<a class="footnote-ref" id="fnref:13" href="#fn:13"><sup>13</sup></a><a class="footnote-ref" id="fnref:14" href="#fn:14"><sup>14</sup></a><a class="footnote-ref" id="fnref:15" href="#fn:15"><sup>15</sup></a> </p> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/Abstraction_principle_(programming)/sch4TIxH">Abstraction principle (programming)</a></li> <li><a href="/facts/Code_duplication/adzaD7R2">Code duplication</a></li> <li><a href="/facts/Code_reuse/DVohfy6U">Code reuse</a></li> <li><a href="/facts/Copy_and_paste_programming/j9GXNpBM">Copy and paste programming</a></li> <li><a href="/facts/Database_normalization/uLCKbIBz">Database normalization</a> and <a href="/facts/Denormalization/pVne4Ckv">denormalization</a></li> <li><a href="/facts/Disk_mirroring/ulg3lVVm">Disk mirroring</a></li> <li><a href="/facts/Loop_unrolling/uasvbJWE">Loop unrolling</a></li> <li><a href="/facts/Redundancy_(engineering)/odqzTmIo">Redundancy (engineering)</a></li> <li><a href="/facts/Rule_of_three_(computer_programming)/mDF2vCrc">Rule of three (computer programming)</a></li> <li><a href="/facts/Separation_of_concerns/Tx8jawNT">Separation of concerns</a></li> <li><a href="/facts/Single_source_of_truth/uXqMNxcz">Single source of truth</a> (SSOT/SPOT)</li> <li><a href="/facts/Structured_programming/zA8b8dP1">Structured programming</a></li> <li><a href="/facts/Edsger_W._Dijkstra/910x0MjT">Two or more, use a for</a></li> <li><a href="/facts/You_aren%2527t_gonna_need_it/rQ60HGso">You aren't gonna need it</a> (YAGNI)</li></ul> <h2 id="external-links">External links</h2> <ul><li>Don't Repeat Yourself at <a href="/facts/WikiWikiWeb/K13WVqo1">WikiWikiWeb</a></li> <li>Once and Only Once at WikiWikiWeb</li> <li><a href="https://web.archive.org/web/20131204221336/http://programmer.97things.oreilly.com/wiki/index.php/Don't_Repeat_Yourself">97 Things Every Programmer Should Know (O'Reilly)</a></li> <li><a href="https://www.red-gate.com/simple-talk/blogs/the-myth-of-over-normalization/">The myth of over-normalization</a> (discussion of academic extremes vs. real-world database scenarios)</li> <li>Wilson G, Aruliah DA, Brown CT, Chue Hong NP, Davis M, Guy RT, et al. (2014). <a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3886731">"Best Practices for Scientific Computing"</a>. <i>PLOS Biol</i>. 12 (1): e1001745. <a href="/facts/ArXiv_(identifier)/H6EtgnBe">arXiv</a>:<a href="https://arxiv.org/abs/1210.0530">1210.0530</a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1371%2Fjournal.pbio.1001745">10.1371/journal.pbio.1001745</a>. <a href="/facts/PMC_(identifier)/dX1zMt71">PMC</a> <a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3886731">3886731</a>. <a href="/facts/PMID_(identifier)/JlHAvMHt">PMID</a> <a href="https://pubmed.ncbi.nlm.nih.gov/24415924">24415924</a>. Don't Repeat Yourself (or Others)</li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>Hunt, Andrew; Thomas, David (1999). The Pragmatic Programmer : From Journeyman to Master (1 ed.). US: Addison-Wesley. pp. 320. ISBN 978-0201616224. <a href="978-0201616224" target="_blank">978-0201616224</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>Dave Thomas, interviewed by Bill Venners (2003-10-10). "Orthogonality and the DRY Principle". Retrieved 2006-12-01. <a href="http://www.artima.com/intv/dry.html" target="_blank">http://www.artima.com/intv/dry.html</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>Object Oriented Software Construction, 2nd edition, page 63 <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>Pai, Praseed; Xavier, Shine (2017-01-31). .NET Design Patterns. Packt Publishing Ltd. ISBN 978-1-78646-186-5. <a href="978-1-78646-186-5" target="_blank">978-1-78646-186-5</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>Justin Lee (2006-03-08). "DRY is for losers". Retrieved 2013-08-31. <a href="http://www.theserverside.com/news/thread.tss?thread_id=39358#203288" target="_blank">http://www.theserverside.com/news/thread.tss?thread_id=39358#203288</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Zig Zichterman (2002-08-08). "JavaOne 2002: Zig's Notes". Retrieved 2024-01-09. <a href="http://ziggr.com/javaone2002/" target="_blank">http://ziggr.com/javaone2002/</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>Kent C. Dodds (2019-04-01). "AHA Programming". Retrieved 2021-05-08. <a href="https://kentcdodds.com/blog/aha-programming" target="_blank">https://kentcdodds.com/blog/aha-programming</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>Sandi Metz (2016-01-20). "The Wrong Abstraction". Retrieved 2021-05-08. <a href="https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction" target="_blank">https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> <li id="fn:9"><p>Bartholomae, Daniel (21 August 2020). "Moist code - Why code should not be completely DRY". The Startup CTO. Retrieved 11 November 2021. <a href="https://startup-cto.net/moist-code-why-code-should-not-be-completely-dry/" target="_blank">https://startup-cto.net/moist-code-why-code-should-not-be-completely-dry/</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li> <li id="fn:10"><p>Haus, Ev (24 December 2020). "Using DRY, WET & DAMP code". Medium. Retrieved 11 November 2021. <a href="https://evhaus.medium.com/using-dry-wet-damp-code-6ab3c8245bb2" target="_blank">https://evhaus.medium.com/using-dry-wet-damp-code-6ab3c8245bb2</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li> <li id="fn:11"><p>Fields, Jay. "DRY code, DAMP DSLs". Jay Fields' Thoughts. Retrieved 11 November 2021. <a href="http://blog.jayfields.com/2006/05/dry-code-damp-dsls.html" target="_blank">http://blog.jayfields.com/2006/05/dry-code-damp-dsls.html</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li> <li id="fn:12"><p>Resnick, Brian (28 April 2016). "Why do so many people dislike the word "moist"? This scientist has a theory". Vox Media. Retrieved 11 November 2021. <a href="https://www.vox.com/2016/4/28/11521048/moist-gross" target="_blank">https://www.vox.com/2016/4/28/11521048/moist-gross</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></p></li> <li id="fn:13"><p>Kent C. Dodds (2019-04-01). "AHA Programming". Retrieved 2021-05-08. <a href="https://kentcdodds.com/blog/aha-programming" target="_blank">https://kentcdodds.com/blog/aha-programming</a> <a href="#fnref:13" class="footnote-back-ref">↩</a></p></li> <li id="fn:14"><p>Dodds, Kent (27 March 2021). "3 Minutes with Kent: Write the code first, then make the abstraction". Briefs. Retrieved 11 November 2021. <a href="https://www.briefs.fm/3-minutes-with-kent" target="_blank">https://www.briefs.fm/3-minutes-with-kent</a> <a href="#fnref:14" class="footnote-back-ref">↩</a></p></li> <li id="fn:15"><p>Dodds, Kent; Bostian, Emma; Nisi, Nick (30 July 2021). "JS Party – Episode #186: Getting hooked on React". The Changelog. Retrieved 11 November 2021. <a href="https://changelog.com/jsparty/186" target="_blank">https://changelog.com/jsparty/186</a> <a href="#fnref:15" class="footnote-back-ref">↩</a></p></li> </ol>