結合を増加させずにDRYを適用することは可能ですか？

関数Fを実装するソフトウェアモジュールAがあるとします。別のモジュールBは、F 'と同じ関数を実装します。

重複するコードを取り除くには、いくつかの方法があります。

1. AにBのF 'を使用させます。
2. BにAのFを使用させます。
3. Fを独自のモジュールCに入れ、AとBの両方に使用させます。

これらのオプションはすべて、モジュール間に追加の依存関係を生成します。カップリングを増加させる代わりに、DRY原則を適用します。

私が見る限り、DRYを適用すると、カップリングは常に増加するか、リースでより高いレベルに移動します。ソフトウェア設計の最も基本的な2つの原則の間には矛盾があるようです。

（実際、そのような競合があることは驚くことではありません。これはおそらく、優れたソフトウェア設計をそれほど難しくしていることです。これらの競合は通常、入門書では扱われていません。

編集（明確化のため）：FとF 'の等価性は単なる偶然ではないと思います。Fを変更する必要がある場合、F 'も同様に変更する必要があります。

これらのオプションはすべて、モジュール間に追加の依存関係を生成します。カップリングを増加させる代わりに、DRY原則を適用します。

なぜそうですか。ただし、回線間の結合は減少します。カップリングを変更する力が得られます。カップリングには多くの形式があります。コードを抽出すると、間接性と抽象性が高まります。それを増やすことは良いことも悪いこともあります。どちらを取得するかを決定する一番の理由は、使用する名前です。名前を見て、中を見て驚いたなら、あなたは誰にも好意的ではありません。

また、真空状態でDRYを追跡しないでください。重複をなくすと、そのコードのこれら2つの使用が一緒に変わることを予測する責任があります。それらが独立して変更される可能性がある場合、混乱と余分な作業を引き起こし、ほとんど利益はありません。しかし、本当に良い名前はそれをより口当たりの良いものにすることができます。あなたが考えることができるすべてが悪い名前であるならば、どうぞ、今すぐやめてください。

カップリングは、システムが非常に隔離されていて、それが機能するかどうか誰にもわからない場合を除き、常に存在します。したがって、カップリングのリファクタリングは、毒を選択するゲームです。DRYに従うことで、変更するのが非常に困難になるまで、多くの場所で何度も同じ設計決定を表現することによって作成されるカップリングを最小限に抑えることができます。ただし、DRYを使用すると、コードを理解できなくなります。その状況を救う最善の方法は、本当に良い名前を見つけることです。良い名前が思いつかない場合は、意味のない名前を避けるのが上手であることを願います

明示的な依存関係を解除する方法があります。人気のあるものは、実行時に依存関係を注入することです。このようにして、DRYを取得し、静的安全性を犠牲にしてカップリングを削除します。今日では非常に人気があり、人々も理解していないので、トレードオフです。たとえば、アプリケーションコンテナは、複雑さを隠すことで、ソフトウェアを非常に複雑にする依存関係管理を定期的に提供します。型システムが不足しているため、単純な古いコンストラクターのインジェクションでさえ、一部のコントラクトを保証できません。

タイトルに答える-はい、可能ですが、ランタイムのディスパッチの結果に備えてください。

• _AのインターフェイスF _Aを定義し、Fの機能を提供します
• _BのインターフェイスF _Bを定義します
• FをCに入れる
• モジュールDを作成して、すべての依存関係を管理します（A、B、Cに依存します）
• DでFをF _AおよびF _Bに適応させる
• AおよびBにラッパーを挿入（パス）します

このように、依存関係の唯一のタイプは、他の各モジュールに依存するDです。

または、組み込みの依存性注入を使用してアプリケーションコンテナにCを登録し、ゆっくりと成長する実行時クラスローディングループとデッドロックの自動配線の幸運を味わってください。

それ以上の文脈のない答えが意味をなすかどうかはわかりません。

Aすでに依存していますBか、その逆ですか？—この場合、私たちはのためのホームの明らかな選択をするかもしれませんF。

良いホームになる可能性のある一般的な依存関係を共有しAてBいますかF？

大きさ/複雑さはF？他に何がF依存していますか？

モジュールAとB同じプロジェクトで使用されていますか？

ウィルAとBとにかく、いくつかの一般的な依存関係を共有して終わりますか？

使用されている言語/モジュールシステム：新しいモジュールは、プログラマの苦痛やパフォーマンスのオーバーヘッドにどの程度苦しみますか？たとえば、モジュールシステムがCOMでC / C ++で記述している場合、ソースコードに苦痛を与え、別のツールを必要とし、デバッグに影響を与え、（モジュール間呼び出しの）パフォーマンスに影響を与えます。いくつかの深刻な一時停止を取ります。

一方、単一の実行環境でかなりシームレスに結合するJavaまたはC＃DLLについて話している場合、それは別の問題です。

関数は抽象化であり、DRYをサポートします。

ただし、優れた抽象化は完全である必要があります。不完全な抽象化は、基礎となる実装の知識を使用して、消費クライアント（プログラマー）が不足を補う可能性が非常に高くなります。

そのためA、B1つの関数を新しいモジュールに単純に移動するよりも、より優れた抽象化を作成し、依存するようにしたいと考えていますC。 

新しい抽象化を引き出すための一連の関数を探しています。つまり、ベースとなるよりも完全/より完全な抽象化リファクタリングを識別するために、コードベースがさらに進むまで待つかもしれません単一の機能コードで伝えます。

この問題を「最小化」することができるすべての方法に焦点を当てたここでの答えは、あなたを傷つけています。また、結合を作成するためのさまざまな方法を単に提供する「ソリューション」は、真のソリューションではありません。

真実は、あなたが作成したまさにその問題を理解していないということです。あなたの例の問題は、DRYとは関係なく、アプリケーション設計と（より広く）関係ありません。

両方が同じ関数Fに依存している場合、モジュールAとBが別々である理由を自問してください。もちろん、貧弱なデザインにコミットすると、依存関係の管理/抽象化/結合/あなたの名前の問題が発生します。

適切なアプリケーションモデリングは、動作に従って行われます。そのため、Fに依存するAとBの部分は、独自の独立したモジュールに抽出する必要があります。これが不可能な場合は、AとBを組み合わせる必要があります。いずれの場合も、AとBはシステムにとってもはや有用ではなく、存在しなくなるはずです。

DRYは、不適切なデザインを公開するために使用できるプリンシパルであり、その原因ではありません。アプリケーションの構造のためにDRYを達成できない場合（実際に適用される場合 -編集に留意する場合）、それは構造が不利になったという明確な兆候です。これが、「継続的なリファクタリング」も従うべき原則である理由です。

他のデザインプリンシパル（ソリッド、ドライなど）のABCはすべて、アプリケーションの変更（リファクタリングを含む）をより簡単にするために使用されます。それに注目すると、他のすべての問題が消え始めます。

これらのオプションはすべて、モジュール間に追加の依存関係を生成します。カップリングを増加させる代わりに、DRY原則を適用します。

少なくとも3番目のオプションについては、私は異なる意見を持っています。

あなたの説明から：

• AニーズF
• BはFが必要
• AもBもお互いを必要としません。

AとBの両方がすでにCの機能を必要としているため、CモジュールにFを配置しても結合は増加しません。