11

以前、複合指向プログラミングに関する InfoQ の記事を読んでいました。

http://www.infoq.com/articles/Composite-Programming-Qi4j

誰かが現在Qi4jフレームワークを使用している (または使用したことがある) かどうかを調べることに興味がありましたか?

クラスを結び付けるために Spring などの従来の依存性注入フレームワークを使用する場合と比較してどうですか。結果のオブジェクト グラフ (クラスではなくミックスインに基づく) は、メンテナンスの観点から扱いやすいですか?

4

6 に答える 6

9

さて、私はプロジェクトでQi4jを約1年間使用しています。ドメイン モデルで mixin の機能に慣れると、以前は mixin なしでどうやって管理していたのか疑問に思うでしょう。実際、ドメイン モデルを作成する POJO メソッドは廃止されるべきだと思います。システム的に保守不可能なコードを作成します。DI ではなく mixin/composite モデルが Qi4j の重要な機能であるため、実際には Java プラットフォームでの比較はありません。

Bozho 氏の懸念については、Mixin の宣言に関しては、2 つのケースがあります。エンティティ、つまりドメイン モデルでは、通常、インターフェイスには 1 つの実装しかありません。実際には、メンテナンスと読みやすさの理由から、複数の実装を積極的に避けたいと思うでしょう。そのため、インターフェイスで直接実装を宣言します。ただし、これはデフォルトにすぎず、必要に応じてコンポジットによってオーバーライドできます。これまでのところ、そうする必要があるとは思いませんでした。

もう 1 つのケースはサービスで、これはまったく異なります。多くの場合、実装は 1 つしかないため、インターフェイスで実装を宣言することはまったく問題ありません。しかし、異なる実装が必要なサービスのケースがはるかに多いため、そのようなケースでは、代わりに具体的な複合型宣言で mixin を宣言するだけです。したがって、両方のスタイルが可能であり、さまざまな理由で推奨されます。

キャストに関しては、オブジェクトをキャストできることはボーナスであり、問​​題ではありません. ある役割から別の役割へのキャストがない場合、それを回避するために非常に独創的である必要があり、おそらくコードが単純になることはありません。

于 2010-02-05T04:18:03.837 に答える
3

カブラム; JPA との統合が複数回試行されました。重複するが完全に互換性のない 2 つのテクノロジがある場合、可能性の交差のみが発生します。したがって、Qi4j と JPA を統合するには、2 つの基本的なアプローチがあります。

  1. JPA オプションを制限して、Qi4j が必要とするはるかに柔軟なデータ構造を完全に使用できるようにします。SQL に直接アクセスする方がはるかにパフォーマンスが高く、それを選択したため、これを行っても意味がありません。

  2. 既存の JPA データ モデルに適合するように Qi4j のデータ モデルを制限します。これを行うと、そもそも Qi4j を選択する理由の利点のほとんどが失われます。そのため、これを行うためにサイクルを費やさないことにしました。しかし、Qi4j の拡張性は、コア ランタイムをハッキングせずにそのような統合を行い、EntityStore を作成するだけで十分だと思います。

于 2012-02-25T09:49:36.277 に答える
2

うまくいけば、この議論は手遅れではありません: しかし、これが私の見方です。

まず第一に、私は Qi4j の背後にあるアイデア (コンポジット、Mixins、アセンブリ) が好きですが、それを使用する複雑さによって妨げられています。

そこにある概念は、フレームワークよりも言語 (Java など) などのより広い傘の一部である必要があり、使いやすくする必要があります。

私は 2 年前に問題に遭遇したので、そのようなことがあればいいのにと思いました。

一連の Bean で再利用できる 3 つの異なる動作が必要でした。一部の Bean はそれらすべてを使用し、他の 2 つを任意に組み合わせて使用​​しました。意味がなかったので、それらすべてをクラスにまとめたくありませんでした。一方で、多重継承ができないという制約がありました。明白な解決策: インターフェイスを使用します。つまり、そのことを何度も実装するということです。インターフェイスのデフォルトの実装を提供する方法があればいいのにと同僚に不平を言ったことを覚えています。私にとってこれは、よりクリーンな方法で動作を再利用できるようにする単純な OO の概念です。また、デフォルトの実装とは異なるものが必要な場合は、それを実装するよりも. それはより理にかなっており、私が見ることができる自然法則を壊すことはありません.

したがって、あなたの質問に答えるために、この Qi4j の概念により、Spring がより構造的であり、概念的に比較することさえできない、よりクリーンな方法で OO を考えることができると思います。依存性注入を考えていて、Spring を考えていなくて、Qi4j を考えていて、Dept インジェクションを考えていない可能性があります。

于 2010-06-07T06:47:48.530 に答える
1

Qi4j の 2 分、10 分などのチュートリアル (最後の 1 つは不完全) を読んだとき、頭に浮かんだ明らかな疑問の 1 つは、これを JPA/Hibernate マネージド エンティティとどのように統合するかということでした。JPA とシームレスに統合するソリューションを期待しています。私の意見では、JPA がないということは、Qi4j が採用されていないことを意味します。Java Enterprise の世界に深く浸透している JPA および Spring との統合を示す著者による記事が見たいです。統合が簡単であれば、急速な採用が続きます。

于 2011-02-23T22:56:38.323 に答える
1

博州; インターフェイスで宣言されているミックスインについて質問がある場合は、

Mixin の実装は、実装のシーク順序が「メソッドごと」に発生し、宣言されたインターフェイスから左から右に進み、次に各スーパーに進むため、「より高い」(つまりサブ) インターフェイスでオーバーライドできますインターフェイス (extend 句でも左から右)。または、コンポジットのアセンブリでオーバーライドできます。

public void assemble( ModuleAssembly module )
{
    module.entities( Account.class ).withMixins( LdapAuthenticatorMixin.class );
    :
}

LdapAuthenticatorMixin は抽象的で、単一のメソッドのみをオーバーライドする場合があります。

于 2012-02-25T09:43:16.403 に答える