DRY 原則が有用でない場合
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2016/06/10 17:56 UTC 版)
「Don't repeat yourself」の記事における「DRY 原則が有用でない場合」の解説
冗長化やミラーリング。 小規模のコンテキストでは、DRY に基づき設計する労力は、二つの別々のデータのコピーを維持管理する労力よりはるかに大きくなる。 DRY 原則を厳守するような標準の強要は、wikiなどのコミュニティの参加に高い価値があるようなコンテキストでは、コミュニティの参加を阻害してしまう。 構成管理とバージョン管理は、DRY 原則を逸脱することなく同じコードのコピーを許容する。たとえば、良い例として開発用の環境、テスト用の環境、製品版コード用の環境を構築し、進行中の開発とテストが製品のコードに影響を与えないようにする方法がある。 人間が読むことができる文書(コードのコメントから印刷されたマニュアルまで)は、通常はコードの内部まで読んで理解する能力や時間がない人のための推敲、説明を加えてコードの内部にあるものを再度記述している。しかし、DRY では、人間が読むことができるドキュメントはフォーマットの変更を除けば何の価値もなく、すなわち記述されるのではなく生成されるべきとしている。 ソースコードの生成 - 重複の禁止はソースコード生成には役立つが、それは出力結果に対してではなく、重複した情報が人間や他のコードによって変更されない場合のみである。 単体テスト - ソースコードとの矛盾を見つけ出すのが目的であり、ソースコードから自動生成すべきではない。ただし、ソースコメントやドキュメントから自動生成する事はありうる。 Abel Avramは、DRYを過度に追求する事で疎結合の原則が破られる例を示し、DRYはあくまで他の原則との兼ね合いの元で守られるべきだと述べている。
※この「DRY 原則が有用でない場合」の解説は、「Don't repeat yourself」の解説の一部です。
「DRY 原則が有用でない場合」を含む「Don't repeat yourself」の記事については、「Don't repeat yourself」の概要を参照ください。
- DRY 原則が有用でない場合のページへのリンク
