私は、数式を解くための一般的なアルゴリズムを実装する A などの DLL を持っています。私は別の DLL、たとえば B を持っています。これは数式を実装します。DLL B はその方程式を解くために DLL A を使用しますが、DLL B は DLL A から与えられた方程式を実行できなければなりません (DLL A はいくつかの数値、近接メソッドを実装し、「試行」します)。必要な数学的解へのステップとして、与えられた方程式の異なる値) ここで、DLL A は DLL B を「知っている」必要があり、逆もまた同様です。
これは「悪い」設計ですか？そんなコードをアマチュアコーセーと考えていいのだろうか？どうしますか (DLL A は、数式を実装する他のさまざまな DLL で使用される一般的なアルゴリズムを実装していることを思い出してください)。
ありがとうデビッド
この問題 (パッケージ間の実装の循環依存) こそが、依存関係逆転原則 (DIP)が作成された理由です。Charles Bailey は、DIP を使用して依存関係を解消するソリューションを提供しました。2 つの具体的なクラス (クラスまたは関数、DIP を適用しても大きな違いはありません) を互いに直接結合する代わりに、それらを抽象化に結合します。
この場合、「数学関数」を定義し、ソルバー DLL によって消費されるインターフェイスがあります。「ソルバー アルゴリズム」を定義し、関数 DLL によって使用されるインターフェイスもあります。抽象化に依存する具体的なクラス/関数があります。C++ の用語では、これらはインターフェイスであり、関数 DLL でメソッドを呼び出すと、ソルバーはそれ自体を「ソルバー インターフェイス」へのポインターとして関数に渡します。この関数は、ソルバー インターフェイスのメソッドを呼び出して、適切なポイントでソルバーにコールバックします。同様に、ソルバーには、数学関数インターフェイスへのポインターを受け取り、適切なタイミングで関数を呼び出すクラスがあります。
Bob Martin の著書Agile Principles, Patterns and Practices in C#では、DIP を含むこれらのオブジェクト指向の設計原則について説明しています。彼は、これらの原則を実際に示す具体的な例を示しています。この本では C# (初版では Java を使用) を使用していますが、同じ原則と実践が C++ にも当てはまります。
DLL A が DLL B について明示的に知る必要がある理由はありません。解くために与えられた方程式を評価できるインターフェイスが必要なだけです。
インターフェイスは関数シグネチャで指定するか、適切な関数へのポインターを B から A に渡すか、抽象クラスとして提示し、実際に派生インスタンスであるものへのポインターまたは参照を B から A に渡すことができます。 A.
相互に依存する dll を持つことは可能ですが、通常はお勧めできません。この場合、私はそれが必要だとは思わない。
A は他の多くの人が使用しているため、古い dll のようです。B を明示的に呼び出すように A を変更する必要があるのは良くないように思えます。これは、A で何度も変更を行う必要があることを示している可能性があります。A を変更すると、他のすべての dll を再構築する必要があるため、これは悪いニュースです。
B に与える任意の形式のコールバック (仮想、コールバック、テンプレート) を導入することにより、B が方程式を実行する方法または A が方程式を解く方法を抽象化する必要があります。A の方が古く、おそらくもっと使用されているので、B を選びます。Solver が A のクラスで、Equation が B のクラスである疑似コードを次に示します。
solver=new Solver;
equation=new Equation(&solver);
ソルバーは、ある種の抽象インターフェースを実装する必要があります。最適なソリューションは、言語とフレームワークによって異なります。「依存性逆転の原則」または「依存性注入」のGoogle。
DLL A がコールバック インターフェイスを発行し、DLL B がインターフェイスに従ってコールバック メソッドを実装し、A を呼び出すときにそれへのポインターを提供するコールバック パターンを実装している場合、これは悪い設計ではありません。
それは良い質問です。はい、それは悪い設計です。2 つのソリューション:
「循環」および/または「非循環」「依存関係」をグーグルで検索すると、このトピックの詳細が見つかる場合があります。