![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>なんとか原則]] *目次 [#afeb9d1d] #contents *概要 [#ec85b2a4] 定義を忘れるためメモ。 *対象 [#m1f0cf4b] 恐らく[[前者（コードを対象としているという主張）>#i6c06441]]が正しい。 様々な参考情報を参考にすると、恐らく、~ [[前者（コードを対象としているという主張）>#i6c06441]]が正しい。 **コードを対象としているという主張 [#i6c06441] 単に「コードを重複させない」という原則ではなく、 -DBスキーマ、 -テスト、 -ビルドシステム、 -ドキュメント なども対象になっており、 「ソフトウェア開発全体において情報を重複させない」 という原則。 **コードを対象としていないという主張 [#n6367ffb] ***[[OAOO(Once And Only Once)]]原則 [#q6d9bd61] 転じて、プログラムコード中で同じ(ような)動作をするコードを何度も書かずに、~ 一度書いたものを再利用するようにすべきとする意味で用いられることもあるが、~ こちらは本来は“[[OAOO(Once And Only Once)]]原則と呼ばれるものである。 ***クラス、オブジェクトに対する適用 [#we38c88a] -DRY はオブジェクト・インスタンス（データ）に対して適用されるのに対して、 -OAOO はクラス（コード）に対して適用される。 *用例 [#w3e98c70] ２つのコンテキストがある。 -業務系などライフサイクルが長いケースでは前者が重視されていると思う。 -Web、ゲームなどライフサイクルが短いケースでは後者が重視されていると思う。 **ポジティブなコンテキスト。 [#d6b5475e] 共通化などを行ったDry。 -大規模なSI案件では、~ チーム開発でも疎結合なDryの状態を維持するため、~ 標準化・共通化などは半ば常識的に行われる。 >密結合なDryの状態で開発されていたら、大規模化して~ 長期の維持・保守が必要になった場合に、対応できなくなる。 -[[Open棟梁>http://opentouryo.osscons.jp/]]導入案件でも、案件毎に、更に追加のレイヤが追加されるので、~ 標準化・共通化のレイヤは、追加されたUIコントロールなどで、かなり分厚くなる。 **ネガティブなコンテキスト。 [#y14f8197] （車輪の再開発はしない的な）素描Dry。 -観測範囲で、Web、ゲームやフリーランス界隈でも、Dryが尊ばれている様に見える。 -しかし、下記のように、「[[Dryで書いたものが負債になっていく。>#odf5da81]]」という発言もあり、~ ライフサイクルが短く、スクラップ・アンド・ビルドなプロジェクトでは、[[デメリット>#odf5da81]]を理解する必要がある。 --≒ モジュール強度が強く、結合度が弱くなる境界で分割されていない。 --≒ デファクトなフレームワークの生のAPIを触りたい為、レイヤ分割を避けている。~ ---フレームワークの生のAPIを触りたい。 ---低品質な≒オレオレ的なレイヤを構築したくない（＆触りたくない）。 ※ なんとなく、時間を掛けて適切な設計が出来無い案件でDryが問題になっているように見える。 *疑問 [#o98f456a] **モジュールの凝集度・結合度との関連 [#k94eeee3] ありそう。 -モジュールとしてまとめられたときに困るのは、~ 凝集度が低く、結合度が高くて、自由度が制限されること。 -モジュール化するべきか、しないべきか、については慎重に考えたい。 **スタックしなくてもDryにできるか？ [#g47ab134] 基本スタックしないとダメそう（素描DryはDryじゃないダロ的な）。 -しかし、凝集度・結合度に問題がある下位スタックだと逆効果。 -こういうこともあって、[[デメリットについての言及>#odf5da81]]も増える。 *参考 [#had64951] -Don't repeat yourself - Wikipedia~ https://ja.wikipedia.org/wiki/Don%27t_repeat_yourself -DRY原則（Don't Repeat Yourself）とは - IT用語辞典~ http://e-words.jp/w/DRY%E5%8E%9F%E5%89%87.html -DRY原則 | プログラマが知るべき97のこと~ https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/DRY%E5%8E%9F%E5%89%87/ -プリンシプルオブプログラミングを読んだ • nemupm~ https://nemupm.com/blog/2018/02/12/principles-of-programming/ **デメリットについての言及 [#odf5da81] -@mizchiさんのツイート: --https://twitter.com/mizchi/status/959297746908856320 >DRY、よかれと思って書かれたものが負債になってることのほうが多くないですか --https://twitter.com/mizchi/status/1078243362640093185 >本当に共通化できるモジュールを発見するのは、~ 技術的な分解点とドメイン理解の双方がないと正しく行うことはできない --@mizchiさんの「DRY」に対する言及コレクション。~ https://twitter.com/search?l=&q=Dry%20from%3Amizchi&src=typd -あなたはDRY原則を誤認している？ - Qiita~ https://qiita.com/yatmsu/items/b4a84c4ae78fd67a364c --DRYは素晴らしい考えですが、やり過ぎると密結合を生んでしまう。密結合が進むと修正時に影響範囲が増えてしまうんですね。 --ソフトウェア開発原則は他にも多数存在するわけで、それぞれコンテキストによって用法・容量を正しく守って使いましょうということでした。 -DRY原則の利用: コードの重複と密結合の間~ https://www.infoq.com/jp/news/2012/05/DRY-code-duplication-coupling --DRYは重複とそれに伴うメンテナンスの問題を軽減するものだが、誤用すると密結合を生み、可読性を損うおそれがある。 --教訓：ソフトウェア開発原則は、ほかの原則やパターン、プラクティスを考慮して適用しなくてはならない。 -DRYと不当な抽象化によるコストについて | POSTD~ https://postd.cc/on-dry-and-the-cost-of-wrongful-abstractions/ >抽象化のコストがコードを重複させるコストを上回らない限り、必ず抽象化する。
