私の意見では、 AOPは興味深いプログラミング パラダイムです。ただし、ここstackoverflowではまだ議論されていません（少なくとも私はそれらを見つけることができませんでした）。一般的にそれについてどう思いますか？プロジェクトで AOP を使用していますか? それとも、それはニッチな技術であり、長い間存在しない、または主流にならない (少なくとも理論的には OOP がそうであったように ;)) と思いますか?
AOP を使用している場合は、使用しているツールもお知らせください。ありがとう！
Python は、実行時にクラスを動的に変更できるようにすることで AOP をサポートします (Python では、通常、AOP ではなくモンキーパッチと呼ばれます)。以下は、私の AOP 使用例の一部です。
すべてのページが Python 関数によって生成される Web サイトがあります。クラスを受講して、そのクラスで生成されるすべての Web ページをパスワードで保護したいと考えています。AOP が助けになります。各関数が呼び出される前に、適切なセッション チェックを行い、必要に応じてリダイレクトします。
プログラムの実際の使用中に、プログラム内の一連の関数のログとプロファイリングを行いたいと考えています。AOP を使用すると、これらの関数を実際に変更することなく、タイミングを計算してデータをログ ファイルに出力できます。
スレッドセーフでない関数でいっぱいのモジュールまたはクラスがあり、それをマルチスレッド コードで使用していることに気づきました。一部の AOP では、ライブラリにアクセスして何も変更せずに、これらの関数呼び出しにロックを追加します。
この種のことはめったに起こりませんが、発生するたびにモンキーパッチが非常に役立ちます。Python には、Decorator デザイン パターン ( http://en.wikipedia.org/wiki/Decorator_pattern ) を実装して同様のことを実現するデコレータもあります。
クラスを動的に変更すると、実際にそのライブラリを変更することなく、バグを回避したり、サードパーティのライブラリに機能を追加したりすることもできることに注意してください。私はこれを行う必要はほとんどありませんが、数回出てくると信じられないほど便利です。
はい。
セキュリティのような直交する問題は、AOP スタイルのインターセプトで行うのが最適です。それが自動的に (依存性注入コンテナーのようなものを介して) 行われるか、手動で行われるかは、最終目標にとって重要ではありません。
1 つの例: xUnit.net (私が実行しているオープン ソース プロジェクト)の「before/after」属性は、AOP スタイルのメソッド インターセプトの形式です。テスト メソッドをこれらの属性で装飾すると、そのテスト メソッドが実行される直前と直後に、コードが呼び出されます。データベースのセットアップや結果のロールバック、テストが実行されるセキュリティ コンテキストの変更などに使用できます。
別の例: ASP.NET MVCのフィルター属性も、特殊な AOP スタイルのメソッド インターセプターのように機能します。たとえば、未処理のエラーがアクション メソッドで発生した場合、それをどのように処理するかを指定できます。
Castle Windsor や Unity など、多くの依存性注入コンテナーは、「そのまま」または拡張機能を使用して、この動作をサポートしています。
AOP を使用せずに、ロギング、セキュリティ、トランザクション管理、例外処理などの分野横断的な問題をクリーンな方法で処理する方法がわかりません。
Spring フレームワークを使用している人 (おそらく Java エンタープライズ開発者の約 50%) は、知っているかどうかにかかわらず AOP を使用しています。
Terracottaでは、AOP とバイトコード インストルメンテーションをかなり広範囲に使用して、サードパーティ ソフトウェアと統合し、インストルメント化しています。たとえば、Springの統合は、 aspectwerkzを使用して大部分が達成されます。簡単に言うと、Spring Bean と Bean ファクトリをクラスター化するために、さまざまなポイントでこれらの呼び出しをインターセプトする必要があります。
そのため、AOP は、他の方法では変更できないサード パーティのコードとの統合に役立ちます。ただし、大きな落とし穴があることがわかりました。可能であれば、参加ポイントでサードパーティのパブリック API のみを使用してください。そうしないと、次のマイナー リリースでプライベート メソッドが変更されてコードが壊れる危険性があります。メンテナンスの悪夢。
AOP とトランザクションの境界は、まさに理想的な組み合わせです。私たちは Spring AOP @Transaction アノテーションを使用しています。これにより、他のどこよりも簡単で直感的な tx-demarcation が実現します。
私の大きなプロジェクトの 1 つでかなり長い間、aspectJ を使用していました。このプロジェクトは、複雑なドキュメント処理/クエリ システムのフロント エンドである複数の機能を持つ複数の Web サービスで構成されていました。約 75,000 行のコード。2 つの比較的マイナーな機能にアスペクトを使用しました。
最初は、アプリケーション フローのトレースでした。各関数呼び出しの前後に実行され、「entered 'function'」と「exited 'function'」を出力するアスペクトを作成しました。関数セレクター (ポイントカットかな? 正しい名前は覚えていません) を使用して、これをデバッグ ツールとして使用し、特定の時点でトレースしたい関数のみを選択することができました。これは、私たちのプロジェクトのアスペクトにとって本当に良い使い方でした。
次に行ったのは、アプリケーション固有のメトリックです。タイミング、オブジェクト情報などをキャプチャし、結果をデータベースにダンプするために、Web サービス メソッドにさまざまな側面を配置します。この情報を取得できたのは良かったのですが、その取得コードはすべて、作業を行った「実際の」コードから分離したままにしています。
アスペクトがもたらす優れた解決策について読んだことがありますが、「通常の」テクノロジーではできなかった (おそらくもっと優れた) ことを、アスペクトが実際にできるとは確信していません。たとえば、私たちのプロジェクトで必要とされていて、アスペクトなしでは簡単に実行できない主要な特徴や機能は思いつきませんでした。 .
セッション ファサードで AOP を使用して、顧客がアプリケーションをカスタマイズするための一貫したフレームワークを提供します。これにより、メソッドごとに手動フックのサポートを追加することなく、カスタマイズの単一ポイントを公開できます。
さらに、AOP は、追加のトランザクションのセットアップとティアダウン、および通常のログ記録のための単一の構成ポイントを提供します。結局のところ、これらすべてを手動で行うよりもはるかに保守が容易です。
私は C# アプリケーションで AOP を多用しています。私は属性を使わなければならないのが好きではないので、Castle DynamicProxy と Boo を使用して、コードを汚染することなく実行時にアスペクトを適用しました。
私が取り組んでいる主なアプリケーションには、スクリプト ホストが含まれています。AOP を使用すると、ホストは、スクリプトをアプリケーション ドメインにロードするかどうかを決定する前に、スクリプトのプロパティを調べることができます。一部のスクリプトは非常に扱いにくいため、これにより実行時の読み込みが大幅に高速化されます。
また、最終的な分散アプリケーションの一部である必要のない、コンパイラ制御、フロー制御、IDE 内デバッグなどのために、かなりの数の属性を使用し、使用する予定です。
AOP ソリューションには PostSharp を使用します。現在使用しているキャッシング、エラー処理、およびデータベースの再試行の側面があり、セキュリティ チェックを側面にする過程にあります。
私たちにとって素晴らしい作品です。開発者は、関心の分離を本当に気に入っています。アーキテクトは、プラットフォーム レベルのロジックを 1 か所に統合することを非常に気に入っています。
PostSharp ライブラリは、コードの挿入を行うポスト コンパイラです。これには、実装が非常に簡単な事前定義されたインターセプトのライブラリがあります。イベントハンドラーで配線するような感じです。