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