Don't repeat yourself

Don't repeat yourself︵DRY︶は、特にコンピューティングの領域で、重複を防ぐ考え方である。この哲学は、情報の重複は変更の困難さを増大し透明性を減少させ、不一致を生じる可能性につながるため、重複するべきでないことを強調する。

DRY は、Andy Hunt と Dave Thomas の著書 The Pragmatic Programmer (邦題:達人プログラマー) において中心となる原則である。 彼らはこの原則を、データベーススキーマ、テスト計画、ビルドシステムや、ドキュメンテーションにいたるまで非常に幅広く適用している 。

DRY 原則がうまく適用されたとき、システムに対するいかなる要素の変更も、論理的に関連のない他の要素の変更にはつながらない。さらに、論理的に関連した要素は予測できる形で統一的に変更され、したがってそれらの変更は同期が取れたものとなる。

Once and Only Once 原則との対比

DRY はアプリケーションに必要な情報︵通例は設定情報︶に対して言及しているという点で Once and Only Once (OAOO) 原則とは区別される。比較すると OAOO はコードの機能的な振る舞いについて言及しており、構造体やオブジェクト指向言語における継承の実現が必要な理由となっている。

たとえば、DRY はファイルの集合の場所はアプリケーションの中で一箇所に格納されるべきと主張するが、これらのファイルからデータを取り出す処理をアプリケーションの異なる箇所で記述する回数については寛容である。OAOO の原則は、これに対して、ファイルからデータを取得するコードは一度のみ書かれるよう求めるが、アプリケーション内でこれらのファイルを配置する場所が何箇所あるかについては寛容である。

さらに混乱を招きやすいのは、アプリケーションの中でオブジェクトは変数として格納され、オブジェクトは情報の一部として見られる点であり、それゆえに DRY はオブジェクトに対して適用される(インスタンスを一つだけ持つ) のに対して、OAOO はクラスに対して適用される。(アプリケーション内で、オブジェクトのクラステンプレートに同じ目的を持つほかのコードがない)という点である。

DRY 原則が有用でない場合

●冗長化やミラーリング。

●小規模のコンテキストでは、DRY に基づき設計する労力は、二つの別々のデータのコピーを維持管理する労力よりはるかに大きくなる。

●DRY 原則を厳守するような標準の強要は、wikiなどのコミュニティの参加に高い価値があるようなコンテキストでは、コミュニティの参加を阻害してしまう。

●構成管理とバージョン管理は、DRY 原則を逸脱することなく同じコードのコピーを許容する。たとえば、良い例として開発用の環境、テスト用の環境、製品版コード用の環境を構築し、進行中の開発とテストが製品のコードに影響を与えないようにする方法がある。

●人間が読むことができる文書(コードのコメントから印刷されたマニュアルまで)は、通常はコードの内部まで読んで理解する能力や時間がない人のための推敲、説明を加えてコードの内部にあるものを再度記述している。しかし、DRY では、人間が読むことができるドキュメントはフォーマットの変更を除けば何の価値もなく、すなわち記述されるのではなく生成されるべきとしている。

●ソースコードの生成 - 重複の禁止はソースコード生成には役立つが、それは出力結果に対してではなく、重複した情報が人間や他のコードによって変更されない場合のみである。

●単体テスト - ソースコードとの矛盾を見つけ出すのが目的であり、ソースコードから自動生成すべきではない。ただし、ソースコメントやドキュメントから自動生成する事はありうる。

●Abel Avramは、DRYを過度に追求する事で疎結合の原則が破られる例を示し、DRYはあくまで他の原則との兼ね合いの元で守られるべきだと述べている。

関連項目

●コードの再利用

●関係の正規化

●KISS原則

●関心の分離

●トランザクション処理︵内部情報の不一致を防ぐための方法論が関連︶

●YAGNI

●重複コード

参考文献

外部リンク

• Orthogonality and the DRY Principle
• List of Pragmatic Programmer rules
• c2.com the original
• Once and Only Once (c2.com)