「重複は悪」としても知られる「Don't repeat yourself」(DRY )は、変更される可能性のある情報の繰り返しを減らし、変更される可能性の低い抽象化に置き換えたり、そもそも冗長性を回避する データ正規化を使用することを目的としたソフトウェア開発の原則です。
DRY原則は、「すべての知識は、システム内で単一の、明確な、信頼できる表現を持つ必要がある」と述べられています。この原則は、Andy HuntとDave Thomasが著書『The Pragmatic Programmer』で定式化しました。[1]彼らはこれを、データベーススキーマ、テストプラン、ビルドシステム、さらにはドキュメントにまで広く適用しています。[2] DRY原則が正しく適用されると、システムのどの要素を変更しても、論理的に関連のない他の要素を変更する必要はありません。さらに、論理的に関連する要素はすべて予測どおりに均一に変更されるため、同期が保たれます。コードでメソッドとサブルーチンを使用するほかに、ThomasとHuntはコードジェネレーター、自動ビルドシステム、スクリプト言語を利用して、レイヤー全体でDRY原則を遵守しています。
単一選択原則
DRYの特別な例として、単一選択原則が挙げられます。これは、ベルトラン・マイヤーによって次のように定義されました。「ソフトウェアシステムが一連の選択肢をサポートする必要がある場合、システム内の1つのモジュールだけがそれらの完全なリストを知っている必要があります。」[3]これは、 Eiffelの設計時に適用されました。
代替案
濡れた
DRY の反対の考え方は WET と呼ばれ、これは一般的にwrite everything twice [4] ( write every time、we enjoy entering、waste every time )の頭文字をとった略語です。WET ソリューションは、開発者が Web アプリケーションのフォームにコメント フィールドを追加するなどのタスクを負うような多層アーキテクチャでよく使用されます。テキスト文字列「comment」は、ラベル、HTML タグ、読み取り関数名、プライベート変数、データベース DDL、クエリなどで繰り返される可能性があります。DRY アプローチでは、最も重要なものを除くすべての編集タスクを削減または排除するフレームワークを使用して冗長性を排除し、新しい知識変数を 1 か所に追加する拡張性を残します。[5] この「DRY」プログラミングの代替としての「WET」の概念化は、少なくとも 2002 年から Java の世界で存在していましたが、この用語の造語者は不明です。[6]
なるほど
抽象化へのもう一つのアプローチは、AHA原則です。AHAは、急いで抽象化を避ける(Avoid Hasty Abstractions )の略で、ケント・C・ドッズによって、まず変化に最適化し、時期尚早な最適化を避けると説明されました。[7]また、サンディ・メッツの「間違った抽象化よりも重複を優先する」という考え方に影響を受けました。[8]
AHA は、エンジニアがソフトウェアの抽象化に多額の投資をすればするほど、その投資のコストは回収できないと認識するようになる (埋没費用の誤謬) という理解に基づいています。したがって、エンジニアは要件が変わるたびに同じ抽象化を繰り返し続ける傾向があります。AHA プログラミングでは、WET ソリューションと DRY ソリューションの両方で、必然的に堅固で保守が難しいソフトウェアが作成されるものと想定しています。抽象化から開始したり、特定の数の重複で抽象化したりするのではなく、必要なときに抽象化を行うか、重複自体が障壁になって抽象化がどのように機能する必要があるかがわかっているときに抽象化を行うと、ソフトウェアはより柔軟で堅牢になります。
AHAプログラミングは、もともとDoddsによって「moist code」と名付けられ、後にDaniel Bartholomaeによって再び名付けられました。 [9]また、 Matt Ryerによって当初はDAMP ( Don't Abstract Methods Prematurely )と呼ばれていました。[ 10]すでにDAMP ( Descriptive And Meaningful Phrases )という別のプログラミング原則があり、Jay Fieldsによって説明されていましたが、[11]コミュニティはmoistという単語に対する文化的嫌悪感から、MOISTの使用に反対しました。[12] DoddsはTwitterで代替案を呼びかけ、 Cher Scarlettの提案であるAHAに落ち着く前にDATEを代替案として提案しました。 [7] [13] [14]
参照
参考文献
- ^ Hunt, Andrew; Thomas, David (1999). The Pragmatic Programmer : From Journeyman to Master (第 1 版). 米国: Addison-Wesley. pp. 320. ISBN 978-0201616224。
- ^ Dave Thomas、Bill Venners によるインタビュー (2003-10-10)。「直交性と DRY 原則」。2006-12-01に閲覧。
- ^ オブジェクト指向ソフトウェア構築、第 2 版、63 ページ
- ^ Pai, Praseed; Xavier, Shine (2017-01-31). .NET デザインパターン。Packt Publishing Ltd. ISBN 978-1-78646-186-5。
- ^ Justin Lee (2006-03-08). 「DRY は敗者のためのもの」。2013 年 8 月 31 日閲覧。
- ^ ジグ・ジヒターマン (2002-08-08)。 「JavaOne 2002: ジグのメモ」。2024-01-09に取得。
- ^ ab Kent C. Dodds (2019-04-01). 「AHAプログラミング」. 2021年5月8日閲覧。
- ^ Sandi Metz (2016-01-20). 「間違った抽象化」 . 2021年5月8日閲覧。
- ^ Bartholomae, Daniel (2020年8月21日). 「Moist code - Why code should not be completely DRY」. The Startup CTO . 2021年11月11日閲覧。
- ^ Haus, Ev (2020年12月24日). 「DRY、WET、DAMPコードの使用」. Medium . 2021年11月11日閲覧。
- ^ Fields, Jay. 「DRY コード、DAMP DSL」。Jay Fields の考え。2021年11 月 11 日閲覧。
- ^ レズニック、ブライアン(2016年4月28日)。「なぜ多くの人が「湿った」という言葉を嫌うのか?この科学者は理論を持っている」。Vox Media 。 2021年11月11日閲覧。
- ^ Dodds, Kent (2021年3月27日). 「3 Minutes with Kent: Write the code first, then make the abstraction」. Briefs . 2021年11月11日閲覧。
- ^ Dodds, Kent; Bostian, Emma; Nisi, Nick (2021年7月30日). 「JS Party – Episode #186: Getting hooked on React」. The Changelog . 2021年11月11日閲覧。
外部リンク
- WikiWikiWebで同じことを繰り返さないでください
- WikiWikiWeb で一度だけ
- プログラマーが知っておくべき 97 のこと (O'Reilly)
- 過剰正規化の神話(学術上の極端な例と現実世界のデータベース シナリオの議論)
- Wilson G、Aruliah DA、Brown CT、Chue Hong NP、Davis M、Guy RT、他 (2014)。「科学計算のベストプラクティス」。PLOS Biol . 12 (1): e1001745。arXiv : 1210.0530。doi : 10.1371 / journal.pbio.1001745。PMC 3886731。PMID 24415924。自分 自身 (または他の人)の
言葉を繰り返さない
