アスペクト指向プログラミングパラダイムを使用する利点と欠点は何ですか[終了]

では、ここで質問です。アスペクト指向プログラミングパラダイムを使用する利点と欠点は何ですか。

これまでの私の長所と短所：

利点：

• オブジェクトの向きを補完します。
• コードの保守性と理解性を向上させる分野横断的な懸念をモジュール化します。

不利益：

• 把握するのが最も簡単な概念ではない-OOほど文書化されていない
• OOは、懸念の分離において十分に進んでいます...

誰かがこれらに挑戦したり、自分のものを追加したいですか？

どうもありがとう、J

「Keep It Simple Stupid」をモットーとするプログラマーの観点からすると、そのようなモデルの使用法を評価することは危険です。それが達成しようとしていることに関して、それはプログラムを理解することをはるかに困難にし、結果として破ることをより簡単にします。

優れたプログラミングの天才は、皮肉にもその単純さにあります。複雑なプログラムは機能するかもしれませんが、メンテナンスに関しては悪夢であり、プログラマーが費やす時間の3分の2がプログラムのエラーの修正に費やされていると考えると、最終的には効果がありません。

運用の範囲から機能を分散すると、複雑さが増し、距離ごとのアクションの問題が増加します。

このような設計手法は、システムが最初から設計されているのではなく、クリーンな動作のためにそれを要求するため、進化すべきものであると考えています。

その他の利点（すべてではない）

• モジュール性のおかげで、クラスとアスペクトの再利用
• モジュール化と再利用によりコーディングのコストを削減
• 他の方法ではいくつかのクラスに実装（分散）されるコードにアスペクトを持たせることができるため、コードが短くなります。
• 主な責任とは無関係のコードをクラスに導入せずに、クラスに動作を追加する機能
• クライアントクラスに知らせずに、メソッド/クラスのセマンティクスを再定義する機能

短所

• cflowなどの一部の構成を使用する場合のランタイムオーバーヘッド

短所：不十分なツールチェーンサポート：-デバッガーとプロファイラーは、「アスペクト指向プログラミング」について知らない可能性があります。これは、すべてのアスペクトが手続き型コードに置き換えられたかのようにコードで機能するためです。