問題タブ [cake-pattern]

私はケーキパターンを介してscalaで依存性注入を行うことについて読んでいます。私はそれを理解していると思いますが、まだ要点が見えないので、何かを見逃しているに違いありません! 単なる抽象フィールドではなく、自己型を介して依存関係を宣言する方が望ましいのはなぜですか?

Programming Scala の例ではTwitterClientComponent、cake パターンを使用して次のように依存関係を宣言しています。

以下のように依存関係を抽象フィールドとして宣言するよりも、これはどのように優れていますか?

DIが実際に発生するインスタンス化時間を見ると（私が理解しているように）、ケーキの利点を理解するのに苦労しています。特に、ケーキ宣言（囲み特性）のために必要な追加のキーボード入力を考慮すると

ここでも抽象フィールドを使用しますが、多かれ少なかれ同じです!:

私はケーキの優位性について何かを見逃しているに違いない! ただし、現時点では、他の方法 (コンストラクター、抽象フィールド) で依存関係を宣言することで何が提供されるのかわかりません。

私の開発では、ロボットの脚の拘束問題を多用しています。Guice で解決する方法は知っていますPrivateModuleが、Scala のケーキ パターンでこれを行う方法は明確ではありません。

理想的には、ブログ投稿の最後にあるジョナス・ボナーのコーヒーの例に基づいた具体的な例を使用して、これがどのように行われるかを誰かが説明できますか? おそらく、左右に設定できるウォーマーを使用して、向きとdef isRightSide?

私はまだScalaのケーキパターンを学ぼうとしています。「コンポーネント」の構成を一元化できるという利点と、それらのコンポーネントのデフォルトの実装を提供できるという利点があるように思われます（もちろんオーバーライド可能です）。

ただし、依存関係を説明するための自己タイプの特性の使用は、懸念領域が混在しているようです。コンポーネントの目的（私は思う）は、そのコンポーネントのさまざまな実装を抽象化することです。ただし、コンポーネントで説明されている依存関係リストは、それ自体が実装上の懸念事項です。

たとえば、ウィジェットでいっぱいのデータベース、特定の種類のウィジェットを検索できるレジストリ、およびレジストリを使用してウィジェットを処理するある種のアルゴリズムがあるとします。

そして今、あなたはそれをいくつかの中央構成にまとめることができます：

別のデータベースに変更したい場合は、ミックスインを変更することで簡単に挿入できます。

しかし...データベースを使用しない 別のレジストリコンポーネントを混在させたい場合はどうなりますか？

別の（デフォルト以外の）実装でRegistryComponentをサブクラス化しようとすると、RegistryComponentはDatabaseComponentの依存関係を含めるように要求します。そして、RegistryComponentを使用する必要があります。これは、トップレベルのAlgorithmComponentが必要とするものだからです。

私は何かが足りないのですか？コンポーネントのいずれかでセルフタイプを使用する瞬間、すべての可能な実装で同じ依存関係を使用する必要があることを宣言しています。

他の誰かがこの問題に遭遇しましたか？それを解決するケーキのような方法は何ですか？

ありがとう！

<:特性の抽象型をwithとnotwithでオーバーライドしたい=（ここでの回答のようにScala Upper Bounds：valueはtypeパラメーターのメンバーではありません）。

ケーキ柄を使いたいのですが、うまくいきません。理由がわかりません。

OK、この例は実行されますが、私の実際のユースケースでは、タイプをオーバーライドしたいのですが、では<:ありません=。t関数にアクセスできないようです。なぜですか？

エラーを返すvalue ping is not a member of S.this.T

この記事で提案されているように、一部のソフトウェアシステムの一部をコンポーネントに分割して完全にモジュール化するためにCakePatternを使用したいと思います。最も単純なケースでは、モック可能なコンポーネント、たとえば、相互に使用する可能性のあるロギング、構成、データベース、スクリプトなどが必要です。コードは次のようになります

ここで、データベースと構成コンポーネント（SomeConfigおよびSomeDatabaseトレイト）はプラグイン可能であり、必要に応じて他の実装に変更できます。それらの実装はcore、データベースと構成の両方を保持するオブジェクトにアクセスできるため、データベースは必要に応じて構成にアクセスでき、その逆も可能です。

したがって、問題は次のとおりです。のような特性SomeDatabaseが大きくなり、単一のファイルに収まらない場合、coreオブジェクトへのアクセスを保持する個別のクラスに分割する方法はありますか？具体的には、connectメソッドSomeDatabaseから別のファイルにコードを移動する必要があるとします。

SomeClassはSomeDatabaseがどのように機能するかの実装の詳細なので、私は明らかにそれを特性にしてアプリケーションに混ぜたくありません。coreオブジェクトへのアクセスを提供する方法はありますSomeClassか？

いくつかの関連リンク：

1. JanMachacekによる依存性注入とケーキパターン
2. Real World Scala：JonasBonerによる依存性注入
3. Scalaでの依存性注入：AdamWarskyによるケーキパターンの拡張
4. Martin Odersky＆MatthiasZengerによるスケーラブルなコンポーネントの抽象化

と同じようにdef someA（でtrait B）どのように使用できますか？（その後）trait AC#MyTypeBA#MyType =:= B#MyType

コンパイルされません：タイプの不一致;

ケーキパターンの大きな制限の1つは、静的であるということです。異なるコーダーによって完全に独立して作成された可能性のある特性をミックスインできるようにしたいと思います。しかし、特性はしません頻繁に混ぜる必要があります。ユーザーには、メインアプリケーションを実行する前に、特性/アセンブリを選択する初期化画面が表示されます。そこで、ユーザー選択選択モジュールで、選択した特性をミックスインしてコンパイルしないのはなぜかという考えが浮かびました。コンパイルが失敗した場合でも、ユーザーはメッセージ（互換性のないアセンブリなど）を返すだけで問題ありません。コンパイルが成功した場合、最上位のUIモジュールは、アセンブリのコンパイル済み部分を含む新しくコンパイルされたクラスをロードし、メインアプリケーションを実行します。実行時の初期化中にコンパイルされるクラスは1つまたは2つだけでよいことに注意してください。残りのコードはすべて正常にコンパイルされている可能性があります。

私はScalaにかなり慣れていません。これは認識されたパターンですか？それに対するサポートはありますか？比較的単純な依存関係の状況でGuiceを使用しなければならないのは気が狂っているようです。アプリケーション内からScalaコンパイラーを簡単に実行できますか？メモリ内で実行し、その出力を不要なファイルを作成せずにメモリから使用できますか？

注：動的に見えますが、この方法は100％静的なままです。

編集すると、MicrosoftのRoslynプロジェクトの推進力の1つは、C＃とVisualBasicでこの種のことを可能にすることでした。しかし、それは強力なMicrosoftチームにとってさえかなり大きなプロジェクトだったようです。

Cake パターンを使用しているプロジェクトにいくつかのマクロを統合する必要があります。そのパターンにより、他の利点の中でもとりわけ、無数の輸入を回避することができたので、それを維持したいと考えています. 現在、トランクの外でテストしているいくつかの実験的なマクロで問題に直面しています。まず、Cake という名前のダミー システムを示します。

APieceはクラスを定義し、BPieceは APiece で定義されたクラスを使用するマクロであると想定され、最後にCPieceがマクロを呼び出します。BPiece の実装をコーディングできなかったので、BPiece はマクロであるべきだと言いました。いくつかの方法を試しましたが、常に次のエラーでクラッシュします。

マクロ コードを読むと、マクロを静的モジュールに含める必要があることが推測できます。システム構造を使用するマクロを展開する方法はありますか?

Scala の明示的に型付けされた自己参照の最も一般的な使用法は、モジュールの依存関係が次のように宣言される「ケーキ パターン」であると思われます。

一般に、ケーキのパターンをしばらく無視するとA、型パラメーターなどの任意の型レベルのものを参照できます。BC

... または抽象型メンバー:

これらのケースのいずれにおいても、 、 、およびは特性であることが知られていないabstract class Inner extends A with B with CためA、Bと書くことはできませんでした。Cここでは、明示的に型付けされた自己参照が必要です。しかし、トレイトを使ったケーキのパターンしか見たことがありません:

この場合、代わりにabstract class Foo extends A with B with C直接書くことができますが、私が間違っていなければ同じ意味です。私は正しいですか？そうでない場合、それらはどのように異なりますか。もしそうなら、なぜ誰もが明示的に型付けされた自己参照を使用しているように見えるのですか?

Scala の多くの新しい言語機能を使用すると、構成可能なコンポーネントシステムを実装し、いわゆる Cake パターンを使用してコンポーネントを作成できます。

Cake パターンで使用される Scala 機能のいくつかには、対応する Haskell 機能があります。たとえば、Scala の暗黙型は Haskell の型クラスに対応し、Scala の抽象型メンバーは Haskell の関連型に対応しているように見えます。これは、Cake パターンが Haskell で実装できるかどうか、またそれがどのようになるか疑問に思います。

Cake パターンは Haskell で実装できますか? そのような実装では、Scala 機能はどの Haskell 機能に対応していますか? Cake パターンを Haskell で実装できない場合、それを可能にするために欠けている言語機能はどれですか?