🅱️ 🚀 🥖 PostSharp アスペクト指向プログラミングと依存性注入 🧚 💼 👨‍👨‍👧‍👦

アスペクト指向プログラミングに関する恐怖、不安、疑念についてのAndres Halesbergとの会話の中で、AOPとDIが競合する概念であるという一般的な混乱と誤解に言及しました。この記事では、これら2つのアプローチのすべての相違点と類似点について説明します。最近、MSDN Magazineの12月号で、Dino Espositoの記事「アスペクト指向プログラミング、インターセプション、統一2.0 」を読んで、とても楽しかったです。これは素晴らしい記事であり、.NET開発に携わる開発者には、その全体を読むことを強くお勧めします。多くのDIフレームワーク、およびいくつかの基本的なフレームワーク（WCF、ASP.NET MVC）と同様に、UnityはインターセプターのようなAOPのような機能を提供します。

依存性注入とは何ですか？

依存性注入は、コンポーネント間の依存関係を減らすように設計されたアーキテクチャテンプレートです。依存関係を減らすことの利点の1つ（密結合アーキテクチャから疎結合アーキテクチャへの移行）は、コンポーネントに関する相互認識を減らすことです。これにより、「実装ではなく、インターフェイスに基づいたプログラム」という設計原則を使用して、タスクのより良い分離が達成されます（元：「実装ではなく、インターフェイスへのプログラム」）クライアントは通常、クラスではなくインターフェイス（interfaceキーワードで宣言したもの）で動作します。私はこのように解釈することを好みます：「プログラムから実装へではなく、プログラムから契約へ」（オリジナル：「実装へではなく、契約へのプログラム」）。この場合のクラスの使用に関する契約は、ドキュメント（および必要に応じて事前条件、事後条件）を備えたクラスのオープン（パブリック）メンバーで構成されます。さらに正確に言うと、「クラスベースではなく、ドキュメントベースのプログラム」。したがって、概念をより適切に分離することだけが目的である場合、実際にはインターフェースは必要ありません。必要なのは、キーワードpublic、Internal、protected、およびprivateだけです。オブジェクト指向の設計では、インターフェースはまったくドグマではないことに注意することが重要です。すべてのフレームワーク開発者がこの哲学を固守しているわけではありません。「Javaクラスライブラリは、.NET開発者がCOMインターフェースを使用した経験が少ないという理由だけで、。

インターフェース（クラスではなく）に基づくプログラミングは、コンポーネントが多くのインターフェース実装で動作する必要がある場合に役立ちます。これが非常に便利になるケースは無数にあります（最終的には、すべてのアーキテクチャが拡張可能であることを望んでいます）。しかし、それに直面しましょう。その後の実装、および別の実装が予期されないことを十分に認識しています。では、なぜここ（インターフェース）を使用するのでしょうか？インターフェイスベースのプログラムの概念を使用する場合、次の2つのオプションがあります。

提供されていないコンポーネントに依存していますが、開発を開始する必要があるため、待つことはできません。さらに重要なことは、今すぐ独自のコードをテストする必要があることです。テスト目的でのみ提供されるまで、このコンポーネントの動作をシミュレート（モック）する必要があります。
一定の状態（たとえばデータベース）、実際のプロセス（たとえば銀行カード処理システム）、または単純に低速または信頼性の低いリソース（Webサービス）に依存しているコンポーネントに依存します。テスト目的でのみ、これらのコンポーネントの動作を独自の実装でシミュレートする必要があります。

これらの状況（実際にはテストに関してのみ発生します）では、最終インストール時にコンポーネントが互いにどのように依存するかがわかっていても、コンポーネントがソースコードに接続されていないことは実際に非常に良いことです。それでは、これらのコンポーネントをどのように結び付けるのでしょうか？そして、Dependency Injectionが効き始めます。依存性注入設計パターンでは、オブジェクトを相互に接続する方法を「コンテナ」に指示し、この「コンテナ」にオブジェクトを相互にバインドするように強制します。実際、コンストラクターを使用してクラスオブジェクトを作成するのではなく、コンテナーメソッドを使用してこれを行います。コンテナは必要な実装を決定し、オブジェクトを作成してそれを返します。

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

依存性注入は、疎結合コンポーネントを相互にリンクする問題を解決します。アスペクト指向プログラミングは、さまざまな問題を解決します。実際、さまざまな機能や機能（監査、ロギング、トランザクション処理など）がほぼすべてのビジネス要件に影響する現実には、AOPはコードの重複を最小限に抑えながら、この複雑な現実をコンパクトなソリューションの形で表現します。コードを監査するためにコードレビューを行いたい場合、私たちの自然な欲求は1つのファイルだけを見ることです。ただし、お客様の特定の管理要件に関連するコードを修正する場合、このコードを見たくありません。ご存知のように、これはオブジェクト指向プログラミングだけでは実現できず、アスペクト指向プログラミングの出現と開発につながりました。

AOPとDIの類似点と相違点

DIとAOPにはいくつかの類似点があります。

どちらも疎結合アーキテクチャを実現します
どちらも機能のより良い分離を実現します。
どちらもメインコードの問題の一部を軽減します。

ただし、DIとAOPは、有用であることが判明した状況では大きく異なります。

DIは、コンポーネントに依存している場合に適しています。コンポーネントの実装方法は関係ありません。
AOPは、多くのコード要素に何らかの動作を適用する必要がある場合に適しています。さらに、ターゲットコードは必ずしもこの動作に依存するわけではありません。

動的プロキシ

それでも、依存性注入はどのようにしてアスペクト指向プログラミングに関連付けられたのでしょうか？はい、DIデザインパターンだけで、新しい動作をコンポーネントに簡単に追加できます。方法は次のとおりです。コンテナへの依存関係を要求すると、インターフェイスの実装を取得することになります。どのような実装を取得するかは推測できますが、多くの場合、それを使ってゲームをプレイします。コンポーネントに何らかの動作（たとえば、トレースの呼び出し）を追加するようにコンテナに要求した場合、オブジェクト自体は取得されません。代わりに、動的プロキシオブジェクトを取得します。プロキシオブジェクトは、ユーザーと要求されたコンポーネントの間にあり、要求した動作を実装します。また、DIフレームワークにはクライアントとコンポーネントの実装の間に動作を埋め込む機能があるため、DIはAOP内での開発を可能にするテクノロジーの1つとして理解されています。

プロキシベースのAOP：何がいいの？

プロキシベースのアプローチで気に入っているのは、AOPがDIコンセプトにどのように適合するかです。 DIは、オブジェクト間の依存関係の使用、プロパティの設定、初期化メソッドの呼び出しなど、コンポーネントを構築する方法でコンテナを構成するのに役立ちます。 XMLファイルのいくつかの依存関係として、またはC＃コードを使用して、アスペクトを簡単に構成できます。コンポーネントの構築とアセンブリが統合されます。

構成ファイルを変更するだけでアスペクトを追加する機能は、非常に便利な機能です。どこかに何らかの問題があるとします。そして、あるコンポーネントへのすべての呼び出しを追跡したいとします。これは、アプリケーション全体を再コンパイルせずに実行できます。これは、適切なデバッグ機能がないランタイム環境で決定的な利点となります。問題を見つけて解決するために、数ヶ月かかる場合があります。

プロキシベースのAOP：何が問題なのですか？

DIフレームワークを使用して実装されるプロキシベースのAOPには、次のような多くの制限があります。

彼らは

インターフェイスを介して実装されたコンポーネントでのみ機能します。コンポーネントの内部にあるすべてのメソッド（パブリックまたはプライベート、静的またはインスタンス）で機能するわけではありません。コンポーネントはアプリケーションの一部であり、原則として多くのクラスを含むことに注意してください。
クライアントコードがコンテナからコンポーネントへのリンクを受け取った場合にのみ機能します。コンポーネントが独自のメソッドを呼び出すか、コンテナを介した直接の対話なしでコンポーネントが呼び出される場合、アスペクトは適用されません。
なぜならアスペクトは実行時に適用され、コンパイル時にチェックを行う方法はありません。 PostSharpなどのビルド時フレームワークでは、コンパイル中にアスペクトを誤用するエラーが発生し、アスペクト開発者にさまざまな方法で正しく実行することさえできます（たとえば、Streamを返すメソッドや、安全関連の側面）;
（a）作業するコードの部分に適用される側面、および（b）作業するコードの部分に適用される側面を理解することは困難です。 PostSharpやAspectJなどの完全なフレームワークは、IDEで詳細をすべて表示できます。これにより、ソースコードの理解が大幅に向上します。
実行時AOPのパフォーマンスは、ビルド時フレームワークよりもはるかに劣ります。少数の「大まかに」設計されたクラスにアスペクトを適用する場合、これは副次的な重要性を持ちます。ただし、数百のクラスに対して動的プロキシを作成すると、パフォーマンスが大幅に低下します。
ダイナミックプロキシは、DIフレームワークのサードパーティの機能にすぎず、たとえ技術的に実現可能であっても、完全なビジョンを実現することはありませんでした。それらは常にメソッドの実装に制限されており、これはPostSharpとAspectJが提供しなければならないものと比較することはできません。

プロキシベースのAOP：いものは何ですか？

開発者が競合するテクノロジーに気を取られることなく、常に何かを練習し始めると、これはリスクになります。何かを常に練習する人は安全だと感じるからです。そして、練習は教義になります。これはTDDで起こり、意味のない詳細レベルでテストを書くことを人々に強制します。また、依存性注入では、すべてのクラスを相互に分離する必要があります。 DIは元々、クラスではなくコンポーネントを分離するために発明されたことを思い出してください。コンポーネントはアプリケーションの一部であり、ブロックではなくオブジェクトです。私たちは（社会からの圧力の下で）テスト要件を満たすためだけに、より複雑なアプリケーションを書くことを余儀なくされているのではないかと心配しています。実際、最終製品の品質の向上にはつながりません。ユニットテストはツールであり、目標ではないことを覚えておく必要があります。究極の目標は、アプリケーションのライフサイクル全体にわたる質の高い作業です。

おわりに

アスペクト指向プログラミングと依存性注入は非常に異なる概念ですが、互いに適しているケースは限られています。これらの状況では、DIの一部としてAOPを使用することは理にかなっています。他のオプションについては、動的プロキシを悪用する（およびこれは解決策ではありません）、またはAOP開発専用のツールを使用するという2つのオプションしかありません。そして、このジレンマは私、PostSharp、または.NETだけのものではありません。同じジレンマは、何を選択すべきかを考えるJavaプログラマー、Spring AOPまたはAspectJにかかっています。 AOPとDIは競合するテクノロジーではありません。 1つのプロジェクトで一緒に使用できます。ただし、各テクノロジーがなぜ作られたのかを理解して理解し、コードの品質に焦点を当てることが重要です。

参照：

PostSharp アスペクト指向プログラミングと依存性注入