問題タブ [cake-pattern]

Cake パターンを使用して、アクタが適切な依存関係を持つようにする方法がわかりません。私はまだこれに取り組んでおり、どこにも例が見つかりません。私は基本的に、従うべきチュートリアル/リソースを探しています。

乾杯、クリス。

現在、Cake パターンを使用していくつかの最適化アルゴリズムを実装しています。私はよく名前衝突の問題にぶつかります。例えば：

ここで、はと特性のconstant両方で定義されていますが、それらの値は異なる場合があります。名前の前に特性名を付けることもできますが、見苦しく脆いものだと思います ( )。それを行うより良い方法はありますか？AddMuldef mulConstant: T

私は自分のプロジェクトでケーキのパターンを使用しようとしましたが、とても気に入りましたが、気になる問題が 1 つあります。

Cake パターンは、すべてのコンポーネントの寿命が同じ場合に使いやすいです。複数の traits-component を定義し、traits-implementation によってそれらを拡張し、これらの実装を 1 つのオブジェクト内で結合するだけで、自己型を介してすべての依存関係が自動的に解決されます。

しかし、ユーザー アクションの結果として作成できる (独自の依存関係を持つ) コンポーネントがあるとします。このコンポーネントは、まだデータがないため、アプリケーションの起動時に作成できませんが、作成時に依存関係を自動解決する必要があります。このようなコンポーネントの関係の例は、ユーザーの要求に応じて作成されるメイン GUI ウィンドウとその複雑なサブアイテム (ノートブック ペインのタブなど) です。アプリケーションの起動時にメイン ウィンドウが作成され、ユーザーが何らかのアクションを実行すると、サブペインが作成されます。

これは、Guice のような DI フレームワークで簡単に実行できます。あるクラスの複数のインスタンスが必要な場合は、Provider<MyClass>;を注入するだけです。次に、そのプロバイダーでメソッドを呼び出すget()と、すべての依存関係MyClassが自動的に解決されます。動的に計算されたデータが必要な場合MyClassは、支援された挿入拡張機能を使用できますが、結果のコードは依然としてプロバイダー/ファクトリに要約されます。関連する概念、スコープも役立ちます。

しかし、ケーキパターンを使用してこれを行う良い方法は思いつきません。現在、私は次のようなものを使用しています：

DefaultSubpaneProvider次に、最上位のケーキを混ぜて、SubpaneProviderサブペインを作成するために必要なすべてのコンポーネントを注入します。

このアプローチの問題は、依存関係 ( modelin ModelContainerComponent) を最上位のケーキから動的に作成されたケーキに手動で渡す必要があることです。これは些細な例にすぎませんが、より多くの依存関係が存在する可能性があり、動的に作成されるケーキの種類も増加する可能性があります。それらはすべて、依存関係を手動で渡す必要があります。さらに、一部のコンポーネント インターフェイスを変更するだけで、複数のプロバイダーで大量の修正が行われる可能性があります。

これを行うためのより簡単でクリーンな方法はありますか? この問題はケーキパターン内でどのように解決されますか?

私は次のようにスカラ特性を持っています -

Cake パターンについて聞いたことがありますが、このようなモッキング特性に Cake パターンを適用する方法がわかりません。

これを行う方法について誰かが指摘できますか？

この質問に続いて、次のことがわかりました。

次のコンパイル エラーが発生します。

これは実際に私が苦労してきたエラーです。誰かがなぜそれが起こるのか説明できますか? 現在、回避策として、各モジュールの実装で構成オブジェクトを明示的にキャストするだけです。

Scala では、以下の依存性注入の方法を使用することに問題はありますか。

今、私たちは物事を配線します

明らかに、Cake パターンは (特に自己型に関して) より高い柔軟性を提供しますが、より単純なユース ケースでは、定型文がはるかに少なくなりますが、コンパイル時のチェックと明確で明確なインターフェイスが提供されます。

Cake パターンを使用して Scala に依存性注入を実装しようとしていますが、依存性衝突が発生しています。このような依存関係を持つ詳細な例が見つからなかったため、ここに私の問題があります:

次の特性があるとします (2 つの実装があります)。

そして、次の 2 つのケーキ パターン モジュール (この例では、どちらも機能を our に依存する API ですHttpClient):

と

両方のモジュールを使用する最終的なアプリを作成するときは、両方httpClientのモジュールに依存関係を提供する必要があります。しかし、モジュールごとに異なる実装を提供したい場合はどうでしょうか? それとも、別の方法で構成された依存関係の別のインスタンスを提供するだけExecutionContextですか?

モジュールごとに依存関係に異なる名前を付けて、モジュール名の前に付けることができますが、それは面倒で洗練されていません。また、モジュールを自分で完全に制御できない場合は機能しません。

何か案は？私はケーキのパターンを誤解していますか?

ケーキパターンを使用する場合、自己型アノテーションを使用するのはいつですか?例えば:

対スタブ定義

またはスタブ値

更新: もう少し具体的に説明します (できれば)。3 つのフォームはすべて、Bar インスタンスの必要性を定義します。したがって、基本的に、いずれかの形式でこのトレイトを混合する非抽象クラスは、Bar の実装を提供する必要があります。私の質問は、自己型注釈を使用して Bar の実装を強制したいのはいつですか。いつ def スタブを使用して Bar を強制および実装したいのか、いつ val スタブを使用して強制したいのか。質問が少し明確になったことを願っています。

ありがとうネッタ