私はAOPの分野で初心者です。 AOPのコンセプトを適用するコードを初めてコーディングしたとき、アプリケーションでクロスカッティングパターンがどのように排除されているかを理解することに感激しました。私はセキュリティ、ロギング、トランザクション、監査などのクロスカッティングパターンをAOPを適用して解決するという考えに圧倒されました。
しかし、最初に私が働いているクライアントにAOPの使用を提案したとき、私は彼らがそれをサポートしていないと言われました。私はAOPがより多くのメンテナンスを意味すると言われました！コードが変更された場合、あなたのポイントカットを変更する必要があります。したがって、適用されたコードを変更するたびに分析し、変更し、テストする必要がありますか？
これについてはどうしますか？なぜ主流企業はAOPの広範な利用にまだオープンしていないのですか？ AOPの世界はどこに行くのですか？アスペクト指向プログラミングの将来
AOPは比較的新しい概念であり、大企業は一般に新しい概念に注意しています。彼らは多くのAOPコードに縛られ、それを維持できる人を見つけることができないのではないかと心配しています。
具体的な批判に関して、それは知られていないか誤解されているようです。 AOPの全体のポイントは、クロスカッティングの問題の領域でコードの重複を減らすことによってメンテナンス作業を削減することです。しかし、コードを理解するのが難しくなるため、メンテナンスが難しくなることは事実です.AOPを使用すると、特定のコードを見るときに、他の場所で定義されたアスペクトがその動作を完全に変更する可能性が常にあります。
個人的に、私はAOPのメリット（実際には多くのクロスカッティングの問題がありますか？）がこの問題を上回るかどうかはわかりません。私がそれを解決するために見ることができる唯一の方法は、IDEのサポートによるものです。 IDEにもっと依存させることは、それほど素晴らしいことでもありません。
傾向は、AOP（つまり中央の宣言的定義）と同様の方法でトランザクションやセキュリティなどの特定の重要なクロスカッティングの問題に対処するが、メンテナンス開発者を混乱させるような完全な権限を与えることはない。
私は最近、AOP（http://video.google.com/videoplay?docid=8566923311315412414）に関するGoogle Videoのプレゼンテーションを見ました。そこでは、Gregor Kiczalesは、基本的にAOPがIDEサポートに依存していると言っています（これは私がとにかく理解したものです）、これは容認できないと思います。 –
本当に。 TextPadを使ってSpringでAOPを行うことができます。それはすべての構成です。 IDEが必要なのはなぜですか？ – duffymo
@duffymo、コードの保守性に必要です。 IDEはアスペクトを定義したコードの部分を表示します。 –
AOPは実際にはうまく機能しない興味深いアイデアの1つです。 JavaはAOPを10年以上利用できましたが、修正されるよりも多くの問題を導入するように思われるため、あまり使用されていません。
AOPのあなたの実際の経験は何ですか？ステートメントを事実に戻すことはできますか？私の経験は全く違っています。一般的なAOPやAspectJは、私が過去5年間に遭遇した最も有用でエレガントで強力なツールの1つです。そして私のために、それはうまく働く。 :-) – kriegaex
アプリケーションでパフォーマンスを最適化する必要があり、AspectJでカスタムプロファイラを作成することにしました。最初はAOPを使用することについて懐疑的でしたが、それは絶対に仕事にとって完璧なツールであることに気付きました。
しかし、私はそれを使用しない多くの仕事があります。アプリケーションの機能に影響する可能性のあるものに使用することには、私は非常に注意が必要です。インダイレクションの追加層と透明性の欠如は、機能を追加したりバグを修正しようとする開発者に多大な問題を引き起こします。
GuiceとSpringのようなフレームワークでのJavaアノテーションとその使用は、AOPに触発されたことを忘れています。私は、Javaの注釈はAOPが今日どこに行くのかと言うでしょう。
私は同意しません。注釈は、（注釈がメソッドボディからヘッダーまでクロスカッティングの懸案事項を移動するため）*少ないほうではあるが、AOPが取り除くのを助ける効果の2つであるにもかかわらず、ソースコードと平均*散漫*の一部です。可能であれば、私はpointcutsをタイプとシグネチャにマッチさせますが、アスペクトの使用のために特別に導入された注釈ではありません。他のフレームワークで使用されている既存のアノテーションがある場合は、それをマッチングに使用しますが、AOP固有のアノテーションは使用しません。これが、私が注釈ベースの@AspectJ構文BTWにプレーンなAspectJ構文を好む理由です。 – kriegaex
私たちはAspectJ AOP実装を使用しており、とても満足しています。あなたは、ツールキットのもう一つの部分であると考えるべきです。これは、いくつかの概念を「通常の」Javaで表現しやすくします。現在、主にJMXインターフェイスを提供するためにこのサービスを使用しています。
もっと多くのIDEがサポートしているはずです（私はあなたにJetBrainsを見ています！）、これは確かに採用を助けるでしょう。
私は、AOPがより多くのメンテナンスを意味すると言われました！
これはちょうど愚かであり、間違っています。 AOPは、コードからノイズを取り除き、ビジネス価値を実現するための努力に集中するための不可欠なツールです。ビジネスルールが変更された場合、コードの新しい変更を反映するために、何千ものフレームワークロジックを巡回する必要はありません。
どのツールと同様、正しく使用する必要があります。私はAOPのロギングが不注意復号化されたクレジットカードをログという事実を回避しなければならなかった：
http://www.agileatwork.com/what-happens-when-you-actually-use-aop-for-logging/
私はあなたが実際にかなり遮断されている長い名前のタグのためにこの質問を作成してご覧ください。あなたはそのようにタクソノミストバッジを達成するつもりはありません。 –
@Ctrl Alt D-1337あなたの話は何ですか？私はバッジコレクションのためにここにいません。 – Jay
programmi？ http://stackoverflow.com/questions/tagged/aspect-oriented-programmi –