アスペクト指向プログラミングパラダイムを使用する利点と欠点は何ですか
では、ここで質問です。アスペクト指向プログラミングパラダイムを使用することの利点と欠点は何ですか。
これまでの私の長所と短所：
利点：
- オブジェクトの向きを補完します。
- 横断的な懸念をモジュール化して、コードの保守性と理解性を向上させます。
不利益：
- 理解するのが最も簡単な概念ではない-O-Oほど文書化されていない
- O-Oは、懸念の分離に十分に役立ちます...
誰かがこれらに挑戦したり、自分のものを追加したいですか？
どうもありがとう、J
「Keep It Simple Stupid」をモットーとするプログラマーの観点からすると、そのようなモデルの使用法を評価することは危険です。それが達成しようとしていることに関して、それはプログラムを理解することをはるかに困難にし、結果として破ることをより簡単にします。
優れたプログラミングの天才は皮肉にもそのシンプルさにあります。複雑なプログラムは機能するかもしれませんが、メンテナンスに関しては悪夢であり、プログラマーが費やす時間の3分の2がプログラムのエラーの修正に費やされていると考えると、最終的には効果がありません。
運用の範囲から機能を分散させると、複雑さや距離ごとのアクションの問題が増加します。
このような設計手法は、システムが最初に設計されたのではなく、クリーンな動作のためにそれを要求するため、進化すべきものであると私は考えています。
追加の利点（すべてではない）
- モジュール性のおかげで、クラスとアスペクトの再利用
- モジュール化と再利用により、コーディングのコストを削減
- 他の方法ではいくつかのクラスに実装（分散）されるコードにアスペクトを持たせることができるため、より短いコード
- 主な責任とは無関係のコードをクラスに導入することなく、クラスに動作を追加する機能
- クライアントクラスに知らせずに、メソッド/クラスのセマンティクスを再定義する機能
短所
- 一部の構成要素を使用する場合のランタイムオーバーヘッド。 cflow
短所：不十分なツールチェーンサポート：-デバッガーとプロファイラーは、「アスペクト指向プログラミング」について知らない場合があります。これは、すべてのアスペクトが手続き型コードに置き換えられたかのようにコードで機能するためです。