問題タブ [cake-pattern]

self-type と extends の動作が異なる構成シナリオを考え出そうとしましたが、これまでのところ見つかりませんでした。基本的な例では常に、依存型のサブタイプである必要のないクラス/特性を必要としない自己型について話しますが、そのシナリオでも、自己型と拡張の間の動作は同じようです。

一方を使用する場合と他方を使用する場合に、構成されたオブジェクトの構成または機能のいくつかの形式が異なるシナリオはありますか?

更新 1:セルフタイピングなしでは不可能なことの例をありがとうございます。情報に感謝しますが、self と extends が可能であるが交換可能ではないコンポジションを本当に探しています。

更新 2:私が持っている特定の質問は、なぜさまざまな Cake パターンの例で、 extends の代わりに self-type を使用する必要があると一般的に述べられているのかということだと思います。拡張でうまく機能しないケーキパターンのシナリオをまだ見つけていません

私たちが持っているとしましょう

次に、との両方 が の値 2 になるはずです。の値がデフォルトの 0 であるため、 mixin すると値 1 になります。同様に、mixinすると値 1になります。さらに、これらが Int ではなく Object である場合、.y2x2CABy2yx2BANullPointerException

私が理想的な世界で望んでいるのは、初期化が怠惰ではなく、初期化の順序が値の依存グラフによって自動的に暗示されることです。つまり、デフォルト値を使用するのではなく、初期化順序を再シャッフルするようにコンパイラに指示する方法です。さらに、私は特性をより小さな特性にリファクタリングしてから、正しい mixin の順序を自分で解決したくありません (5 つの特性を mixin しなければならない巨大なプロジェクトでは、これを解決するのは苦痛です)。

更新：別の言い方をすれば...特性をミックスするとき、特性を互いに重ね合わせると想像しますが、valsに関しては実際にはこのようには機能しません...このように機能させる方法

更新: それが本当に不可能な場合は、「overlay」と呼ばれるキーワードを scala に追加するという行に沿って使用できるタイプセーフの既存の機能要求チケットへのリンクを誰かが共有できれば幸いです。の：

私はしばらくscalaを学び始め、今はケーキのパターンを見ています。ここから例を取得しました

私には、JPA リポジトリをサービスに注入するには定型コードが多すぎるように見えます。

ただし、このコードは、はるかに少ない行数で同じことを行います

両方のシナリオをインスタンス化します。

2 番目のシナリオでは、はるかに少ないコードを使用し、DI を使用します。ケーキパターンがもたらす追加の利点を理解するのを手伝ってもらえますか.

Scala Slick-3.1.0 lib を使用しています。

TableQuery インスタンスを入力として受け取り、同じスリック フィルターを作成する汎用のスリック フィルター関数を作成するにはどうすればよいですか?

DBに格納されたデータを表すいくつかのケースクラス(たとえば2つ)があります。一部のフィールドは同じであるため、クラスは共通の祖先を継承する可能性があります。

それらのそれぞれは、DB に独自の SQL テーブルを持ち、個別の SlickTableクラスによって表されます。また、それらは同じ主キーを持っています:

最後にTableQuery、クラスは次のとおりです。

firstDataTableQueryorsecondDataTableQueryを引数として取り、入力に対して同じ洗練されたクエリを作成する一般的な Slick フィルター クエリ関数を作成するにはどうすればよいですか 。共通のフィールドでのみフィルタリングするか、SQL テーブル表現で共通の列を別の方法でフィルタリングします。たとえば、次のようにします。

このトピックを調べましたが、まだ解決策を見つけることができませんでした:

Slick 3 再利用可能な汎用リポジトリ

scala.slick.lifted.TableQuery をインスタンス化するための Scala リフレクション