1990 年代後半から 2000 年代前半にかけて、アスペクト指向プログラミング (AOP) が「次の大物」になるはずだったことを覚えています。最近ではまだ AOP がいくつか見られますが、背景に消えてしまったようです。
3534 次
5 に答える
41
2000 年代初頭に多くの誇大広告があったかもしれませんが、実際に起こったことは次のとおりです。アスペクト指向のフレームワークを作成するための多くの試みがあり、これらの試みは Java 分野の 2 つの重要なプロジェクトに統合されました: AspectJ と春のAOP。AspectJ は完全で、複雑で、アカデミックで、やや過剰に設計されています。Spring AOP は、ユースケースの 80% を 20% の複雑さでカバーします。
「AspectJ、Spring AOP」という用語で Google Trends を見ると、Java 自体の人気と比較すると、AspectJ の相対的な人気はやや一定ですが、Spring AOP は上昇しています。つまり、人々は AOP を使用していますが、AspectJ の複雑さは望んでいません。AspectJ の作成者は多くの戦術的な間違いを犯したと思います。AspectJ は常に研究プロジェクトであり、「大衆向け」に設計されたものではありません。
.NET の分野では、2000 年代初頭に AOP に対する同様の関心が見られました。2003 年に私が AOP の調査を開始したとき、.NET 用の AOP ウィーバーは 6 人ほどいました。全員が AspectJ の道をたどり、全員が幼児期にありました。これらのプロジェクトはどれも生き残りませんでした。この分析に基づいて、20% の複雑さで 80% のユース ケースをカバーするように設計された PostSharp を構築しましたが、Spring AOP よりもはるかに使いやすくなっています。PostSharp は現在、.NET の主要なアスペクト ウィーバーと見なされています。PostSharp 2.0 は、5 年間のフィードバックと AspectJ の業界での経験に基づいて構築され、「エンタープライズ対応」の AOP をもたらします (この主張が値するかどうかは今後判断されます)。PostSharp 以外の重要なプレーヤーは、Spring Framework for .NET と Windsor Castle です。これら 2 つの DI 中心のアプリケーション フレームワークは、「また」を提供します。アスペクト (アスペクトは、構築されたオブジェクトに注入された依存関係と見なされます)。これらのテクノロジはランタイム ウィービングを使用するため、技術的な制限が厳しく、実際にはサービス オブジェクトでのみ使用できます (これらのアプリケーション フレームワークは、そのために設計されています)。.NET のもう 1 つの開始プロジェクトは LinFu で、これは「また」側面を実行できます。
手短に言えば、AOP ランドスケープは昨年ある程度の統合を経ており、おそらく生産性のフェーズに入っています。顧客は、クールだからではなく、本当にお金を節約するためにそれを使用します。それがとてもクールだとしても:)。
ああ、忘れていました。ほとんどのアプリケーション サーバーには、AOP のサポートが組み込まれています。JBoss、WebSphere、そしてある程度は WCF について考えています。
于 2009-11-20T13:31:29.213 に答える
5
それは、「次の大物」ごとに発生する傾向があります。多くの誇大宣伝に続いて、流行語の使用がゆっくりと減少しました。しかし、たとえバズワードが薄れ、最終的に消えたとしても、その背後にある良いアイデアが何であれ、メインストリームに吸収される傾向があります.
[編集] さて、私が何かを「バッシング」していると考えている人、またはアスペクト指向プログラミングが消えようとしていると主張している人のための例です。かつて、次の大きな話題は構造化プログラミングでした。オブジェクト指向プログラミングはそこから生まれ、今では誰も「構造化プログラミング」について語ることはありません。しかし、多くの点で、OOP がその最良のアイデアを採用し、改善し、さらに新しいアイデアを追加したため、私たちはまだその最良のアイデアを使用しています。
于 2008-11-25T02:08:19.310 に答える
5
最近のプロジェクトでの私自身の経験は、悪用するのが簡単すぎるということです:( !!! デバッグ、タイミングを設定し、トランザクション管理を拡張するための良い方法を始めたのは、すぐに最も奇妙なものに破損しました。そして、私がしばらく見た中で最も理解しにくく、デバッグしにくいコードです。
デバッグ/診断側で少し拡張すると、AOP コードによって生成されたスタック トレースは、多くの場合、例外が発生した実際の場所を認識できないほど隠します。
于 2008-11-25T02:24:10.323 に答える
4
AOP は実際には本当に素晴らしいものですが、それに関する問題は、既存の言語がそれを十分にサポートしていないことです。確かに C# には属性があり (コーディングしている場合にのみ機能します)、Java には「インジェクション」があります (これによりランタイムが混乱します)。 ..
つまり、最終的には「デザインパターン」（すべての言語で非常に異なる実装を伴う）になったようなもので、結局それほど悪くはないと思います;）
于 2008-11-25T02:26:28.667 に答える
2
十分な大きさではなかったことをお勧めします。とても魅力的に聞こえますが、コーディングが本当に簡単になるのでしょうか? 私はこれを試して、実際にどのような利点があるかを知りたいと思っていましたが、それが提供する関係が必要な場所で十分なコーディングを行っていないと思います. 私はそれが聞こえるほど有益ではないと思います。
また、この時点で、マルチコア プログラミングをより簡単に行えるようにすることは大きなことであり、アスペクト指向プログラミングがそれを支援するとは思いません。
Adoption Risksにも多くのコンテンツがあります。
于 2008-11-25T02:23:36.130 に答える