問題タブ [decoupling]

私は違いについて一般的な直感を持っていますが、データベースがグローバル状態と異なる理由を正確に特定することはできません.

「グローバル状態」の単純な定義により、データベースは通常、少なくともアプリケーショングローバルです。実行中にデータベースを変更するアプリを使用することも考えられますが、一般的にはグローバルに使用されます。

状態に関しては、データベースに状態が含まれている場合について議論する必要はないと思います。

では、データベースが「悪い」種類のグローバル状態と異なるのはなぜでしょうか?

この質問は、オブジェクトがその親について知る必要がある密結合を回避しようとしているために発生しました。

たとえば、戦略ゲームをプレイしていて、ユニットの 1 つに、敵ユニットにダメージを与えると、そのユニットの所有者が x ゴールド (x は与えられたダメージの量) を失うという能力があるとします。

通常の状況では、ユニットは自分の所有者が誰であるかを知る必要はありません。所有者はユニットを制御する人なので、所有者はユニットにコマンドを発行するだけで、ユニットはその役割を果たします。

ただし、外部要因により、ユニットの所有者が誰であるかを調べる必要が生じます。この場合、攻撃しているユニットは攻撃しているユニットを知っているので問題ありません。しかし今では、攻撃しているユニットを知ることに加えて、所有者が 5 ゴールドを失うようにするために、所有者をさらに知る必要があります。

元の質問から意図した以上に逸脱してしまいましたが、ゲームの状態がリレーショナル データベースに保存されている場合、ユニットが所有者を直接知る必要なく、ターゲットの所有者を照会するのは簡単です。そのようなデータベースがオブジェクトである場合、そのデータベースはすべての状態を完全に把握しており、さらに変更可能であるという意味で、そのデータベースを神のオブジェクトと呼びます。

では、データベースがグローバルな状態と異なるのはなぜでしょうか?

ストラテジーパターンを特定の状況に適用しようとしていますが、各具体的なストラテジーを、そのデータを提供するコンテキストオブジェクトに結合しないようにする方法に問題があります。以下は、いくつかの異なる方法で発生するパターンの単純化されたケースですが、同様の方法で処理する必要があります。

特定の時間枠に関連するデータを提供するオブジェクトがありAcquisitionます。基本的には、さまざまなハードウェアを使用して収集された一連の外部データです。含まれているデータの量のためにすでに大きすぎるので、それ以上の責任を負わせたくありません。ここで、このデータの一部を取得する必要があります。いくつかの構成に基づいて、対応する電圧をハードウェアに送信します。

したがって、次の（非常に単純化された）クラスを想像してください。

ここで、すべての具体的な戦略クラスを私の取得クラスに結合する必要があります。これは、アプリケーションの中核であるため、変更される可能性が最も高いクラスの1つでもあります。これは、クラス内の巨大なswitchステートメントであった古い設計をまだ改善したものです。Acquisitionデータの種類ごとに変換方法が異なる場合があります（Batteryは単純なパススルーですが、他のデータはそれほど単純ではありません）。そのため、戦略パターンなどを使用する必要があると思います。

IAnalogOutputterまた、最終的な実装では、インターフェイスではなく抽象クラスになることにも注意してください。これらのクラスは、ユーザーが構成可能でXMLファイルにシリアル化されるリストに含まれます。リストは実行時に編集可能で記憶されている必要があるため、Serializableは最終的なソリューションの一部である必要があります。それが違いを生む場合に備えて。

最も重要なクラスの1つに結び付けずに、各実装クラスが機能するために必要なデータを確実に取得するにはどうすればよいですか？それとも、私はこの種の問題に完全に間違った方法で取り組んでいますか？

MVCパターンを実装する必要があるかなり大きなSwingアプリケーションを作成しています。現在、アプリケーションは次のようになっています。

かなりの数のビューがあります。これらは階層的に作成され、1つのメインビューに複数のビューが含まれ（そして作成され）、すべてに独自のサブビューのセットなどが含まれます。これらの各ビューは、モデルを呼び出すことにより、他のビューから独立してモデルから情報を取得します。必要に応じて静的メソッド。

また、すべてが完全に分離されているコントローラーもかなりあります。各コントローラーはビューに属します。各ビューは独自のコントローラーを作成し、コントローラーをリスナーとしてユーザー入力に追加します。コントローラーはビューからイベントを受け取り、モデルの静的メソッドを使用してモデルを変更します。ビューがモデルに影響を与えず、ビューにのみ影響を与えるイベントをディスパッチする場合、ビューはこれらのイベント自体を処理します-イベントについてコントローラーに通知することはありません。つまり、コントローラーはビューをまったく認識せず、コントローラーの目的はモデルの操作のみを処理することです。| 編集：コントローラは現在、ビューへのアタッチメントです。これらには、イベント処理のロジックのみが含まれています。つまり、コントローラー自体はコンポーネントではなく、コンポーネントは含まれていません。これらは、次の例と同じ方法で実装されます。MVCの例|

アプリケーションのモデルは非常に受動的であり、リスナーさえありません（データベースを表します）。コントローラからアップデートを受信します。

この例では、ビューがコントローラーを所有しています。一般的なケースでは、コントローラーがビューを所有して作成し、ビューがコントローラーを認識しないようにすると、その逆ではなく、より良いでしょうか？その場合、なぜですか？これはどのように設計されますか？そうでない場合、コントローラーがまだビューを認識しない、より良い設計はありますか？それとも、最高のデザインはどちらでもないのでしょうか？

編集：

元のMVC定義で述べられているように：

「ビューはこの相互通信を確立する責任を負います...」という行は、ビューがコントローラーを作成するか、少なくともコントローラーへの最初の参照を持っていることを示しているようです。その逆はありません。

したがって、これは少なくともそれを行うための可能な方法です（これは有効なMVCパターンです）が、主な問題は残っています。どちらが良いですか、そして最高のデザインはどのように見えるでしょうか？特に、それぞれのビューに密接に関連している多くのコントローラーを扱う場合はどうでしょうか。

編集：コントローラーを参照するビューの別の例： Oracleの例

本当に良いiOSアプリをいくつか調べて、それらがどのように組み合わされているかを確認したいと思います。「complete」を指定したのは、戦術よりも戦略の現在の目的に関心があるためです（ただし、コードも戦術的によくできていることを願っています）。「完全」は「大」を意味する必要はありません。

私自身の最初の優先事項は、全体的なデザインがココアイディオマティックである（つまり、Appleが提供してくれたものをうまく利用する）ことであり、関連するデザインの制約内で可能な限り分離されたクラスに重点を置いています。しかし、私は、特定の公開されているコードベースが綿密な調査に値する正当な理由を与える答えに興味があります。

編集：ここでの私の主な焦点はアプリですが、ライブラリの有益な例も興味深いかもしれません。

C# でクリーンな分離コードを作成する利点として、動的パラメーターを使用してオブジェクトを構築することについてフィードバックを得たいと考えていました。通常、インターフェイスを作成し、そのインターフェイスをコントラクトとして使用すると思いますが、すべてのクラスのインターフェイスを作成する必要があり、ちょっと面倒だと思います...

だから、私の質問は、このようなことをすることの長所と短所は何ですか:

対

さまざまなリクエストを受け取る SOAP-Webservice を実装しています。Manager クラスは、実装クラスに委譲する前に、この Request オブジェクトを内部表現に変換する必要がありますか?

デカップリングに関しては、これは良い考えだと思います。ただし、これを行うには、各 RequestObject クラスのコピーを作成し、元の Request と同じデータを格納する InternalRequestObject という名前を付ける必要があります。

これは理にかなっていますか？

GUI コンポーネントの階層のルートである Component という抽象基本クラスがあるとします。このような場合、Button と Label の 2 つのサブクラスがあり、どちらも抽象クラスであり、具象クラスのそれぞれの階層のルートとして存在します。

Button から継承する具象クラスには、RoundButton および SquareButton が含まれる場合があります。

Label から継承する具体的なクラスには、TextLabel と PictureLabel が含まれる場合があります。

最後に、Component オブジェクトのコレクションを保持する集約 Container クラスがあるとします。

問題は、コンポーネント オブジェクトへのポインターがあることですが、それらがボタンまたはラベルのいずれかであることを識別する必要があります。たとえば、すべてのボタンの内部テキストに大きなフォントを使用するように指定したい場合、コンテナ内のすべてのコンポーネント オブジェクトを反復処理して、どのボタンがボタンであるかを何らかの方法で特定し、ボタン固有のメソッドを呼び出すことができます。

これらのコンポーネント「ファミリ」が自身を識別する 1 つの方法は、文字列を使用することです。

これは、コンポーネントがこれらのファミリを定義するタスクをその子に任せているという点で疎結合です。どのファミリが存在するかを知る必要はありません。クライアントはさまざまなコンポーネント ファミリを認識している必要がありますが、何らかの操作で特定のコンポーネント ファミリをターゲットにしようとしている場合、それは避けられません。

ただし、非常に高いパフォーマンス要件があり、文字列の比較を避けたいとします。また、インライン化できるように、この関数を仮想化することは避けたほうがよいでしょう。また、Component のすべてのサブクラスがグローバル定数を宣言する必要がある場合は、何らかの方法で Component クラスを変更して、これを要件にするか不要にするのがよいでしょう。

この問題の解決策の 1 つは、Component.h で列挙子を定義することです。

この場合、 getFamilyID() は COMPONENT_FAMILY 列挙型を返すだけでよく、基本的には int を比較するだけです。残念ながら、これは、新しいコンポーネント ファミリをこの列挙型に「登録」する必要があることを意味します。これは簡単ですが、他のプログラマにとって完全に直感的ではありません。また、カーディナリティが非常に低い (理想的ではない) ことがわかっている非静的 COMPONENT_FAMILY メンバーを作成しない限り、メソッドは依然として仮想である必要があります。

この問題を解決する良い方法は何でしょうか? 私の場合、パフォーマンスが重要であり、enum ソリューションに似たもので十分に簡単に思えますが、より良い方法を見落としているのではないかと考えています。

--- 編集 ---
実際のシステムでは、同等のコンテナは各ファミリから 1 つのコンポーネントしか保存できないことをおそらく指摘する必要があることを認識しています。したがって、コンポーネントは実際には次のようなマップに格納されます。

ここでの私の簡単な例に当てはめると、これはコンテナに 1 つのボタン、1 つのラベルなどしか含めることができないことを意味します。

これにより、特定のタイプのコンポーネント (ログ時間) の存在を簡単に確認できます。したがって、この質問は、COMPONENT_FAMILY を表す方法と、コンポーネントをマップに追加するときにコンポーネントのタイプを決定する方法に関するものです。

つまり、コンポーネントの唯一の目的は、コンテナに追加された特定の機能として識別され、すべてのコンポーネントが一緒になってコンテナの特定の動作を定義することです。

したがって、コンポーネントのタイプを知る必要はありません。それは既に暗示されています。具体的には、コンテナに特定のタイプのコンポーネントを要求しています。私が必要としているのは、最初にマッピングできるように、コンポーネントがそのタイプを伝達する方法です。

GUIウィンドウのコールバッククラスを作成しようとしています。（うまくいけば）それを達成するために、私はデリゲートを使用しています。

MESSAGE_TYPEは列挙型です。

私が必要としているのは、クラスデストラクタの変更に依存しない、ある種の永続的/一定のインデックスを介して、オブジェクトが破棄されたときにマップからオブジェクトの登録を自動的に解除する何らかの方法です。

つまり、特定の署名に一致するようにコールバックを指定するため、私の計画はゼロから欠陥がある可能性があります（これらの高度なものではまだハーフブラインドでコーディングしています）。したがって、本質的に、この機能を使用するクラスにはいくつかが必要です。それに一致するメソッド、したがって、すでにそれらのルール（クラスに結合されている）に従うことを強制されています。

だから私はそれらの中に地図への参照を置くかもしれません。ただし、それだけでも、マップ内のすべてのエントリを繰り返し処理し、破棄されるオブジェクトに一致するエントリを削除する必要があります。

ですから、私が必要としているのは、ある種の自己認識定数参照ポインターインデックスのものだと思います。

そのようなものは存在しますか？それは一般的な問題であるはずだと私には感じます...

たとえば、ビルドまたはデプロイ プロセスについて議論し、それが IDE から独立していることを確認する場合などです。これは「カップリング」ですか、それとも懸念の分離と見なされますか、それともまったく異なるものですか? 一般的な概念は、プロセスまたはアーキテクチャに導入する変数の数を最小限に抑えることです。これにより、障害が発生した場合に、障害の可能性のあるポイントを特定する難しさが大幅に軽減されます。そのための別の定義はありますか？

モード (通常は列挙型で表される) をコマンドの実装とその関係から切り離す方法は? モード スイッチ (int、enum、string、...) とそのコマンド呼び出しの間の緩やかな結合を説明する良いパターンですか? 構成を介してモードを追加したいので、これは（動的に）簡単に拡張可能でなければなりません（プログラミングなしで）。コマンド パターン (C#/.Net の ICommand) は既に知っています。それはコマンドの辞書とそれに関連するモード番号かもしれませんが、切り替えロジックはどうでしょうか?