アスペクト指向プログラミングは誤称ですか？

「アスペクト指向プログラミング」または「アスペクト指向ソフトウェア開発」について私が学んだすべてから、それをプログラミングのパラダイムまたは方法論として分類することは不正確であるように見えます。私が言えることから、それはプログラミングの基本的なテクニックではありません。

「パラダイム」と「方法論」の意味を明確にするために、アメリカ遺産辞典の次の定義を参照してください。「オブジェクト指向プログラミング」がどれだけ適切に適用されるか、AOPがどれほど適切に適用されるかを比較します。

パラダイム：特に知的分野において、それらを共有するコミュニティの現実を見る方法を構成する一連の仮定、概念、値、および実践。

方法論：専門分野で作業する、または調査に従事する人々が使用する一連の実践、手順、および規則。作業方法のセット。

「エビデンスに基づく医療」はパラダイムの定義を満たしますが、「子宮摘出術に基づく医療」は問題の空間が狭すぎるため、誤った名称になります。

「指向プログラミング」という接尾辞に基づいて、AOPが「オブジェクト指向プログラミング」と同じようにパラダイムと方法論の両方であると主張しているため、AOPの名前が間違っているかもしれないという印象を受けています。

これらの用語（パラダイムと方法論）はどちらも基本的な手法を示しており、アスペクトについて理解しているのは、狭い問題のスコープを解決するためのテクノロジーであり、Javaの静的変数機能に匹敵するかもしれません。

アスペクトが限られた一連の問題を解決し、AOPが誤称ではない場合は、「継承指向プログラミング」、「依存関係」など、すべてのプログラミング手法に「指向プログラミング」接尾辞を付けるべきではないのは事実です。指向プログラミング」または「スコープ指向プログラミング」

「方法論」と「パラダイム」と「指向プログラミング」の定義はこのコンテキストでは少し緩い可能性があるため、これは本当に不明瞭な問題だと思いますが、私は悪魔の支持者を演じ、「はい、それは誤称です。」

問題を解決するためにAOPまたはAOP機能を使用しなかったとしても、それらの側面について考えていることでしょう-どこかでドキュメントとして書かれているかもしれませんし、コードジェネレーターを使用しているかもしれません-どちらにせよ、コンセプト側面のまだあります。それはまた、どんなパラダイムでも行くことができます。かなり醜いですが、CでOOPを行うことはできます。

つまり、AOPがOOPと同じ方法論であることを意味しているのではないでしょうか。それ以外にもあると思います。

その理由は、方法論が特定の種類の問題の解決策を提供するからです。より大きなスキームで2つ以上を使用する場合でも、概念的な問題を解決するために複数の方法を使用することはありません。OOPと手続き型を使用してデータ入力UIを作成する場合がありますが、OOPを使用してUIの抽象的な構造を記述しているだけで、手順（より正確にはメソッド）を使用してその動作を記述しています。問題の中心的な構成要素では、方法論は相互に排他的です。AOPは、機能コード、OOPコード、または手続き型コードの問題の解決に参加できます。

AOPは繰り返しコードの量を減らすという意味で問題を解決しますが、それは言語機能の職務記述の範囲内です。コンパイラーまたはランタイムに明示的に記述する必要のないコードを挿入するように言っても、実際の問題は概念的にはまだ解決していません。コードをもう少し整理しました。「すべての関数が開始時刻と終了時刻をログに記録する」と宣言することは問題の解決策ではありません。これは問題の説明にすぎません。

言語の特徴として、単に「アスペクト」と呼ぶほうが適切だと思います。

すべての開発方法論は、コードの編成について考える方法にすぎません。それぞれの開発方法によって、見た目が非常に異なるコードが生成される場合や、同様のコードが生成される場合があります。また、サポートのためにライブラリまたは言語機能が必要になる場合もあります。

たとえばC ++では、AOPは通常、特性クラスとコンパイル時のポリモーフィズムを使用して実装されます。これは言語の「機能」ではありません。タイプのさまざまな側面を構築し、それらをテンプレートと自由に組み合わせます。

テンプレートのようなものがないJavaのような言語AspectJでは、アスペクト指向の方法でプログラミングするために、プリプロセッサ（たとえば）によって提供される専用の言語機能を使用する必要があります。真のAOP自体を実装します。

結果として、AOPプログラムはJavaと比較してC ++では非常に異なって見えますが、最も重要なのは、プログラマーがコードの外観ではなく、自分のデザインについてどのように考えているかです。

したがって、AOPは確かに開発方法論です。

ここでは、プログラミングのパラダイムとソフトウェア開発の方法論の 2つが関係しています。

はい、アスペクト指向プログラミングはプログラミングパラダイムです。特定の言語機能を利用して、タスクを実行するため、またはコードを読みやすくするために必要な構造を表します。プログラマーが利用できるテクニックです。多くの場合、横断的な懸念を取り除くために、オブジェクト指向プログラミングと並行してAOPが使用されています。ただし、関数型言語の上にアスペクト指向プログラミングを実装することもできます。。これは必ずしも完全に新しいパラダイムではなく、既知の問題を緩和するためのOOPおよび関数型プログラミングの拡張です。それがパラダイムと見なされるべきだと私が信じる主な理由は、それが問題の解決策に到達することに対するあなたの考え方を変えることです。関数型プログラミング、手続き型プログラミング、論理プログラミング、オブジェクト指向プログラミングのすべてが同じ問題に対して大幅に異なるソリューションを持っているように、アスペクト指向プログラミングは問題セットにさらに別のソリューションを追加します。

いいえ、アスペクト指向プログラミングは開発方法論ではありません。開発方法論は、ソフトウェアシステムの作成に使用できるフレームワークです。要件からサポート終了まで、実行するタスクとその実行方法を指定します。AOPはこれについて何も述べていません。ただし、一部のプログラミングパラダイムは、ソフトウェアライフサイクルの開発方法論アプローチにつながりました。Ivar Jacobsonによって開発されたオブジェクト指向ソフトウェアエンジニアリングと呼ばれるアプローチがありましたこれは、オブジェクト指向システムの設計と開発の完全なライフサイクルを指定していましたが、支持されなくなり、UMLとRational Unified Processに置き換えられました。正直なところ、OOPのようにAOPが方法論に影響を与えることはありません。実際、傾向を見ただけでは、方法論はソフトウェアの構築に使用される言語とパラダイムを超越する必要があることを示しているようです。AOPに焦点を合わせたモデリング手法と、設計および開発中に使用される語彙があるかもしれませんが、AOPを中心とした本格的な手法は見当たりません。