アスペクト指向プログラミング弱点？

Question

アスペクト指向プログラミングの大きな弱点はありますか？私はその側面の中で一つのクラスに向かって呼び出しを制限することによって、クロスカット問題を緩和する考えが好きです。しかし、私にとってはちょっと変わっています。

質問1. Loggerクラスの例を見てみましょう。すべてのクラス/メソッドは、Loggerクラスのメソッドを呼び出す必要があります。 Loggerのアスペクトにこれらの呼び出しをすべて書き込むことで、将来の変更が容易になります。しかし、誰がロガーの側面を維持すべきですか？ Loggerクラスの開発者がこれを行う場合は、プロジェクト全体をグローバルに表示する必要があります。プロジェクトが十分に大きければ不可能だと思います。一方、誰もがLoggerのクラスを変更できるようにすると、同じコードにアクセスする人が非常に多くなります。いずれかが間違っていると、コードは失敗します。だから、一般的には、誰がその側面を維持すべきか？

質問2パフォーマンスは問題になりますか？ 1つのポイントカットは、1つのイベントリスナーを登録するようなものだと思います。実行時にポイントカットが多すぎると、プログラムが遅くなりますか？

おかげで、

Answer 1

質問は1

私は、これは主に質問に答えると思う：ロガーの局面は、Loggerクラス/実装と同じではありません。ロガーの実装は、実際にロギングのタスクを実行するスタンドアロンユニットに存在することができますが、ロギングの側面はアプリケーションのドメイン内に存在し、インターセプトで作業を延期することができます。したがって、責任はアスペクトが適用されているエンティティにローカライズされますが、これは理にかなっています。

質問2

Perhaps of interest。

パフォーマンスは非常に具体的なものであり、どのようにして誰がそれを行うのかはわかりませんが、コンパイルされた（または効果的にコンパイルされた）状況では、アスペクトのビヘイビアを効果的に '注入' （または同様の目的を達成するために）適切な場所に配置してください。パフォーマンスヒットは最小限に抑えられます。

これを解釈した言語にすると、事実上実際にはイベントリスナーのオーバーヘッドスタイルになります。

弱点

私は専門家だが、私は結論のカップルを描いて、任意の追加を招待します：可視性の

• 欠如。どのアスペクトに影響しているかをターゲットで確認することはできません。特に、コードフローに影響を与える場合は、デバッグの難しさにつながります。良いIDEサポートはおそらくこれを緩和することができます。
• アスペクトがコードにコンパイルされている場合、おそらく大きなバイナリになる可能性がありますが、これは無視できると思います。

これが役に立ちます。