3

次のような結果になる可能性があります。

    ServiceChild (class) extends (or only partial implements) Service and overrides sayHello
    Service (interface) implements hello,goodbye

    Hello (has a mixin HelloMixin) has method sayHello
    Goodbye (has a mixin GoodbyeMixin) has method sayGoodbye

ServiceChild の懸念アプローチを使用して上記のことを試しました

    public class ServiceChild extends ConcernOf<Service> implements Hello 
 {

    @Override
    public String sayHello() {
     return "Rulle Pharfar";
    }
 }

ただし、このアプローチを使用すると、Hello 実装のみが Java によって検出され、Service クラスの残りのものは検出されません。それで、うまくいく他のアプローチはありますか？

4

2 に答える 2

2

私も質問の意味がよくわかりません。

Arvice が言うように、Concerns は AOP の around-advice と同等であり、はるかに正確なポイントカット セマンティクスを備えています。懸念が根底にある懸念/ミックスインを「ラップ」することは技術的には正しいですが、私はそれを「ラッパー」ではなく「インターセプター」と考えることを好みます。処理されるのは着信コールです。概念が若干異なり、すべての人に当てはまるとは限りません。

クラスを「抽象」にするだけで、Concerns (ステートレス) と Mixins (ステートフル) の両方が、オーバーライドするインターフェースのメソッドのサブセットのみを実装することも可能です。Qi4j は、欠落している (および未使用の) メソッド呼び出しを埋めます。そして、任意の組み合わせを使用することができます。

さらに、適切に実装された懸念事項は、実際の使用法を認識していないため、'next' を呼び出す必要があります。懸念事項がメソッド呼び出しを処理することが期待される場合。複合型メソッドごとに Mixin が必要です。そうしないと、アセンブリが失敗します。

要するに; 1. Mixin 実装は、ゼロ (別名プライベート mixin)、1 つまたは複数の複合型インターフェイスのメソッドを実装できます。2. 懸念は、複合型インターフェースの 1 つ以上のメソッドを実装できます。

クラス (ミックスインまたは懸念事項) が複合型インターフェイスにある独自のメソッドの 1 つを呼び出す場合、呼び出しはクラス内ではなく、外部から複合を呼び出すことに注意することも興味深いです。 stack が呼び出され、内部呼び出しと外部呼び出しの結果が同じになるようにします。これをバイパスする必要がある場合は、パターンが存在します。

于 2013-09-17T16:54:21.200 に答える