「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>FrontPage]]

*目次 [#afeb9d1d]
#contents

*概要 [#ec85b2a4]
定義を忘れるためメモ。

*詳細 [#m1f0cf4b]
恐らく[[前者（コードを対象としているという主張）>#i6c06441]]が正しい。

**コードを対象としているという主張 [#i6c06441]

単に「コードを重複させない」という原則ではなく、
-DBスキーマ、
-テスト、
-ビルドシステム、
-ドキュメント

なども対象になっており、

「ソフトウェア開発全体において情報を重複させない」

という原則。

**コードを対象としていないという主張 [#n6367ffb]

***OAOO(Once and Only Once) [#q6d9bd61]
転じて、プログラムコード中で同じ(ような)動作をするコードを何度も書かずに、~
一度書いたものを再利用するようにすべきとする意味で用いられることもあるが、~
こちらは本来は“Once and Only Once”(OAOO)原則と呼ばれるものである。

***クラス、オブジェクトに対する適用 [#we38c88a]
-DRY はオブジェクト・インスタンス（データ）に対して適用されるのに対して、
-OAOO はクラス（コード）に対して適用される。

**用例 [#w3e98c70]
２つのコンテキストがある。

***標準化・共通化などによるコントロール [#d6b5475e]
小規模なスクラップ・アンド・ビルド案件が、大規模化して維持・保守が必要になった場合に、~
密結合なDryの状態で開発されていたら、標準化・共通化などによるコントロールが必要になった時点で、~
対応できなくなるため、[[Open棟梁>http://opentouryo.osscons.jp/]]導入案件でも、案件毎に、更に追加のレイヤが追加される。

***（オレオレ的な）共通化レイヤを構築したくない。 [#y14f8197]
観測範囲で、Webやフリーランス界隈では、Dryが尊ばれている様に見えるが、~
下記の「Dryで書いたものが負債になっていく。」という発言もあり、[[密結合のデメリット>#odf5da81]]を理解する必要がある。
下記の「Dryで書いたものが負債になっていく。」という発言もあり、~
[[密結合のデメリット>#odf5da81]]を理解する必要がある。

-≒ モジュール強度が強く、結合度が弱くなる境界で分割されていない。

-≒ デファクトなフレームワークの生のAPIを触りたい為、レイヤ分割を避けている。~
--フレームワークの生のAPIを触りたい。
--低品質な≒オレオレ的なレイヤを構築したくない（＆触りたくない）。

*参考 [#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/

**密結合のデメリットについての言及 [#odf5da81]
-@mizchiさんのツイート:

--https://twitter.com/mizchi/status/959297746908856320
>DRY、よかれと思って書かれたものが負債になってることのほうが多くないですか

--https://twitter.com/search?l=&q=Dry%20from%3Amizchi&src=typd
--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/
>抽象化のコストがコードを重複させるコストを上回らない限り、必ず抽象化する。
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS