依存関係の注入を伴うUIの膨大な量のインターフェイスを回避する方法
問題
最近、シングルトンが悪いことと、依存性注入（「インターフェースを使用する」と理解している）がどのように優れているかについて、多くのことを読みました。コールバック/インターフェース/ DIを使用してこの一部を実装し、インターフェース分離の原則に準拠した場合、結局は混乱しました。
基本的にそのすべての子の依存関係を組み合わせたUI親の依存関係。つまり、UI要素が階層の上位にあるほど、そのコンストラクターは肥大化していました。
UI階層の最上位にあるのはApplicationクラスで、現在の選択に関する情報と、変更を反映する必要のある3Dモデルへの参照を保持していました。アプリケーションクラスは8つのインターフェイスを実装していましたが、これは製品（/インターフェイス）の5分の1に過ぎません。
私は現在、現在の選択を保持するシングルトンと、自分自身を更新する機能を持つUI要素を使用しています。この関数は、UIツリーとUI要素を細流化し、必要に応じて現在の選択シングルトンにアクセスします。コードはこのように私にはきれいに見えます。
質問
シングルトンはこのプロジェクトに適切でしょうか？
そうでない場合、私の考えやDIの実装に根本的な欠陥があり、DIを非常に扱いにくくしていますか？
プロジェクトに関する追加情報
タイプ：ベルとホイッスル付きのアパートの買い物かご
サイズ：コードとUIに2人月
メンテナンス：実行中の更新はありませんが、後で「バージョン2.0」になる可能性があります
環境：エンティティコンポーネントシステムを使用するUnityでのC＃の使用
ほとんどすべての場合、ユーザー操作はいくつかのアクションをトリガーします。たとえば、ユーザーがアイテムを選択したとき
- そのアイテムとその説明を表示するUIパーツを更新する必要があります。このため、価格を計算するために3Dモデルから情報を取得する必要もあります。
- uIをさらに上に行くと、全体の合計価格を更新する必要があります
- 3dモデルのクラスの対応する関数を呼び出して、そこに変更を表示する必要があります
問題は症状ではなく、解決策だと思います。
私は最近、シングルトンが悪いことと、依存関係の注入（「インターフェースを使用する」と理解しています）がどのように優れているかについて、多くの記事を読みました。コールバック/インターフェース/ DIを使用してこの一部を実装し、インターフェース分離の原則に準拠した場合、結局は混乱しました。
問題を探す解決策。それと誤解はおそらくあなたのデザインを壊しています。これを読みましたかSOについての質問 DI vsシングルトン、異なる概念かどうか） 私はそれを単にシングルトンをラップするように読んだので、クライアントはシングルトン。それはその場にあると思います。
uI要素の階層が上に行くほど、そのコンストラクターは肥大化しました。
最初に小さいビットを構築してから、それらを所属するもののコンストラクターに渡し、その大きいものを次の大きいもののコンストラクターに渡します...
複雑な構造の問題がある場合は、ファクトリーまたはビルダーのパターンを使用してください。結論として、他のクラスをきちんと、きれいに、わかりやすくするために、独自のクラスに組み込まれた複雑な構造があります。
アプリケーションクラスは8つのインターフェイスを実装していましたが、これは製品（/インターフェイス）の5分の1に過ぎません。
これは拡張機能がないことのように聞こえます。コアデザインが欠けており、すべてが上から詰め込まれています。さらにボトムアップの構造、構成、継承が行われているはずです。
あなたのデザインは「トップヘビー」かしら。 1つのクラスをすべてまたは何かにしようとしているようです。また、ビジネスドメインクラスではなくUIクラスであるため、懸念の分離について本当に不思議に思います。
デザインを最初から見直して、より複雑な、または異なるカテゴリーの作品を作成するために構築できる、堅固で基本的な製品の抽象化があることを確認してください。次に、これらのもののカスタムコレクションを用意して、「コレクションレベル」機能をどこかに配置できるようにします。
...変更を反映する必要がある3Dモデル。
これの多くはカスタムコレクションクラスに適合します。深さと複雑さのため、それ自体が独立したクラス構造になる場合もあります。これら2つは相互に排他的ではありません。
ビジターパターンについてお読みください。これは、機能のチャック全体を異なるタイプに抽象的に配線するという考えです。
デザインとDI
これまでに行う依存性注入の90％は、コンストラクターのパラメーターの受け渡しです。 その本を書いたクィーはそう言う 。クラスを適切に設計し、DIコンテナーを使用する必要があるという漠然とした概念で思考プロセスを汚染しないようにします。あなたがそれを必要とするなら、あなたのデザインはいわばそれをあなたに提案します。
アパートショッピングドメインのモデリングに焦点を当てます。
ジェシカシンプソンのデザインへのアプローチは避けてください ：「それが何を意味するのか完全にはわかりませんが、それが欲しいのです。」
以下は間違っています：
- インターフェイスを使用することになっています
- シングルトンを使うつもりはない
- DIが必要です（それが何であれ）
- 継承ではなく構成を使用することになっています
- 相続を避けることになっている
- パターンを使用する必要があります
「階級制」は少々赤旗です。仮説：5つのウィジェットを持つWebページ。このページはウィジェットの祖先ではありません。これらのウィジェットへの参照を保持する場合があります。しかし、それは祖先ではありません。クラス階層の代わりに、コンポジションの使用を検討してください。 5つのウィジェットは、他のウィジェットやトップページを参照することなく、独自に構築することができます。次に、トップページは、基本ページを作成し、それに渡されるウィジェットオブジェクト（コレクション）をレイアウトするのに十分な情報を使用して作成されます。ページはレイアウトなどを担当しますが、ウィジェットの構築とロジックは担当しません。
コンポジションを使用すると、DIはあなたの親友です。 DIを使用すると、DIで定義したバージョンやウィジェットタイプに合わせて各ウィジェットを交換できます。ウィジェットの構築はDIに取り込まれ、トップページとは別です。おそらく、コレクションの構成もDIで定義できます。トップページは、渡されたウィジェットに基づいて、必要に応じてレイアウトを実行します。トップページのコンストラクタを変更する必要はありません。トップページは、ウィジェットのレイアウトを実行し、定義されたインターフェースに基づいてウィジェットとの間で情報を渡すためのロジックのみを必要とします。
構成のチェーンを上下にリスナーを渡す代わりに、リスナーのコレクションを、それを必要とするウィジェットに注入します。コレクションをパブリッシャーに挿入して、コレクションにパブリッシュできるようにします。コレクションにリスナーを追加できるように、コレクションをリスナーに注入します。コレクションは、構成のチェーン内のすべてのオブジェクトを横断します。