「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
定義を忘れるためメモ。
対象 †
様々な参考情報を参考にすると、恐らく、
前者（コードを対象としているという主張）が正しい。
コードを対象としているという主張 †
単に「コードを重複させない」という原則ではなく、
- DBスキーマ、
- テスト、
- ビルドシステム、
- ドキュメント
なども対象になっており、
「ソフトウェア開発全体において情報を重複させない」
という原則。
コードを対象としていないという主張 †
転じて、プログラムコード中で同じ(ような)動作をするコードを何度も書かずに、
一度書いたものを再利用するようにすべきとする意味で用いられることもあるが、
こちらは本来は“OAOO(Once And Only Once)原則と呼ばれるものである。
クラス、オブジェクトに対する適用 †
- DRY はオブジェクト・インスタンス（データ）に対して適用されるのに対して、
- OAOO はクラス（コード）に対して適用される。
用例 †
２つのコンテキストがある。
- 業務系などライフサイクルが長いケースでは前者が重視されていると思う。
- Web、ゲームなどライフサイクルが短いケースでは後者が重視されていると思う。
ポジティブなコンテキスト。 †
共通化などを行ったDry。
- 大規模なSI案件では、
チーム開発でも疎結合なDryの状態を維持するため、
標準化・共通化などは半ば常識的に行われる。
密結合なDryの状態で開発されていたら、大規模化して
長期の維持・保守が必要になった場合に、対応できなくなる。
- Open棟梁導入案件でも、案件毎に、更に追加のレイヤが追加されるので、
標準化・共通化のレイヤは、追加されたUIコントロールなどで、かなり分厚くなる。
ネガティブなコンテキスト。 †
（車輪の再開発はしない的な）素描Dry。
- 観測範囲で、Web、ゲームやフリーランス界隈でも、Dryが尊ばれている様に見える。
- ≒ モジュール強度が強く、結合度が弱くなる境界で分割されていない。
- ≒ デファクトなフレームワークの生のAPIを触りたい為、レイヤ分割を避けている。
- フレームワークの生のAPIを触りたい。
- 低品質な≒オレオレ的なレイヤを構築したくない（＆触りたくない）。
※ なんとなく、時間を掛けて適切な設計が出来無い案件でDryが問題になっているように見える。
疑問 †
モジュールの凝集度・結合度との関連 †
ありそう。
- モジュールとしてまとめられたときに困るのは、
凝集度が低く、結合度が高くて、自由度が制限されること。
- モジュール化するべきか、しないべきか、については慎重に考えたい。
スタックしなくてもDryにできるか？ †
基本スタックしないとダメそう（素描DryはDryじゃないダロ的な）。
参考 †
デメリットについての言及 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
