アスペクト指向プログラミング（AOP）の短所は何ですか？

Question

アスペクト指向プログラミングの可能性がある重大な欠点は何ですか？例えば

：初心者のための不可解なデバッグ（読みやすさの影響）

Answer 1

• 悪いツールチェーンのサポート - デバッガ、プロファイラなどがAOPについて知らないかもしれないので、すべての側面が置き換えられていたかのようにコードに取り組むこと手続き型コード
• コードの膨張 - 小さなソースコードとしてはるかに大きなオブジェクトコードにつながる可能コードベース

Answer 2

を通じて「織り込ま」されて、私は重大な欠点、それを呼び出すことはありませんが、私が見てきた最大の問題は、開発者の経験と適応能力。宣言型プログラミングと命令型プログラミングの違いを理解している開発者はいません。

EntLib 4.1ではpolicy injection application blockをかなり広く使用していますが、DIの場合はUnityと非常によく似ています。私は自分のアプリケーションが何故何を期待どおりに行動していないのかを何度も繰り返し説明しています。それは一般的に何かを説明して、私は "その方法の上のその宣言を参照してください。 :)いくつかの人々はすぐにそれを取得し、それを愛し、非常に生産的になる - 他の闘争。

学習曲線はAOPに固有のものではありませんが、平均的な開発者が遭遇する他のものよりも学習曲線が高いようです。

Answer 3

メンテナンスとデバッグ。 aopを使用すると、突然コードが特定のポイント（メソッドのエントリ、終了など）で実行されますが、コードを見るだけでは、特にaop設定が別のファイルにある場合、xml configのように。アドバイスによっていくつかの変更が加えられた場合、アプリケーションのデバッグ中に説明がないと不思議に見えることがあります。これは初心者にのみ影響しません。

Answer 4

私は、最大の欠点はAOPをよく使うことだと思います。人々はそれが意味をなさない場所でそれを使用し、たとえばそれがどこで使用されるのかはわかりません。

たとえば、工場パターンは、DIがうまくいくので、AOPがうまくいくことは明らかですが、戦略パターンと同様にAOPを使用するとオブザーバパターンが簡単になります。

実行時に製織すると単体テストが難しくなります。

実行時に製織するとパフォーマンスが低下します。

AOPをクラスに混ぜるときに何が起こっているのかをモデル化する良い方法があると、UMLのように私はその時点で良いモデルだとは思わない。

Eclipseを使用していない限り、ツールには問題がありますが、EclipseとAJDT AOPを使うとはるかに簡単です。

たとえば、junitとnunitを使用しているので、ユニットテストを実行できるようにコードを修正する必要があります。特権モードを使用するとAOPはプライベートメソッドをテストしてユニットテストを改善できます単体テストで動作させるためにプログラムを変更してください。これは、AOPがどのように役立つかを実際に理解していない別の例です。ユニットテストのフレームワークや現在のデザインパターンの実装では、いままで多くの方法でチェーン化されており、AOPがどのようにコーディングを改善するのか分かりません。

Answer 5

メンテナンス/デバッグの議論に関して、アスペクト指向プログラミングは、アジャイルソフトウェア開発の実践の他のすべての側面と関連している傾向があります。

これらの方法は、画像からデバッグを削除し、ユニットテストとテスト駆動開発に置き換える傾向があります。

また、アドバイスなしで大規模で分かりにくいコードフットプリントよりも小さく、明確なコードフットプリントを維持する方がはるかに簡単です（アドバイスは、大規模で分かりにくいコードフットプリントを小さく小さくクリアコードフットプリント）。

Answer 6

AOPの力があるため、クロスカットのバグがあると、問題が広がる可能性があります。その一方で、誰かが意図的な結果を伴わずに、アスペクト・ライターが期待しなかった方法で、プログラム内の結合ポイントを変更することができます（メソッド名の変更や移動など）。クロスカット問題をモジュール化する利点の1つは、プログラマがシステム全体に簡単に影響を与えることができるようにすることです。

Answer 7

私は最大の問題は、誰もが側面のセマンティクスを定義する方法を知らない、またはポイント非手続きに参加宣言する方法ということだと思います。

アスペクトが埋め込まれるコンテキストとは独立してアスペクトが何をしているのかを定義できない場合、またはアスペクトが埋め込まれるコンテキストにダメージを与えないような方法でエフェクトを定義する場合、あなた（そしてツール）は信頼できるものを理由に考えることができません。 （最も一般的なアスペクトの例は、「ロギング」ですが、これはかなり安全なため「アプリケーションが何も知らないログストリームに何かを書き込む」と定義されています）。これは、David Parnasの重要な考えであるinformation hidingに違反しています。私が見ている側面の最悪の例の1つは、同期プリミティブをコードに挿入するものです。コードが持つ可能性のある相互作用のシーケンスに影響します。アプリケーションがあまりにも些細なことをしない限り、これは安全です（デッドロックしないこと、ライブロックしないこと、保護しないことはありませんか？同期パートナーの例外がスローされた場合でも回復できます）。

通常、結合ポイントは、「DataBaseAccess *」という名前のメソッドにこの種の識別子を指定することで定義されます（これは、影響を受けるメソッドを記述している人は、コードを面白い方法で名前を付けることによってアスペクト化するコード、それはほとんどモジュールではありませんさらに、アスペクトの犠牲者はそれが存在することを知る必要がありますか？何が必要なのか、どこに注入するのか、あなたのアプリケーションは壊れます。何が必要なのは、意図的なというジョイントポイントの仕様で、どういうわけか、各使用ポイントにネオンサインを置くことなくプログラマーが必要な場所を知る必要があります。いくつかのコントロールフロー関連のジョインポイントがありますが、これはこのregでは少し良く見えますard）。

面は面白いアイデアですが、技術的に未熟だと思います。そしてその未熟さは、彼らの使い方が壊れやすくなります。それが問題の原因です。 （私は自動化されたソフトウェアエンジニアリングツールの大きなファンです。