OOPテクノロジーの死[終了]
回答:
あるソフトウェアテクノロジーが別のソフトウェアテクノロジーを殺すか、市場全体/使用/聴衆全体を支配すると誰かがあなたに言ったときはいつでも、これを覚えておいてください：
健全な（動的だが安定した）生態系は、さまざまな種から成り立っています。
つまり、新しい誇大広告技術は誇大広告の曲線をたどり、最終的には、時間と経験を通じて、その特定の目的を見つけることになります。
これは、アスペクト指向プログラミングなどの極端な概念が必要な場合に役立つことを意味します。つまり、暗黙のコストのために、常にではなく、それほど頻繁ではありません。
しかし、OOProgrammingのように、汎用プログラミングのように、関数型プログラミングのように、手続き型プログラミングのように、すでにその場所があります。
使用頻度が高く（論争の的になっている人気があり）、実生活で広く普及している言語は「純粋ではない」ことに気づきましたか？これは、いくつかのパラダイムを許可することで、時間の経過に応じてコンテキストを柔軟に変更できるようになり、使用法のニッチを埋めることができるためです。
AOPが原因でOOPが死ぬことはありません。AOPはいくつかの価値を追加しますが、OOPと完全に共存しています。関数型プログラミングがOOPを殺すとは思いません。OOPは、さまざまな種類の問題ドメインに適しているため、機能パラダイムに置き換えることは意味がありません。
パラダイムは行き来しますが、レガシーコードは永遠です。維持するC ++コードは常に存在するため、OOPが完全になくなることは決してありません。
短い答え：いいえ、そうは思いません。
より長い答え：私がAOPについて理解していることから、それはそれ自体はプログラミングパラダイムではなく（たとえば、それはOOPに取って代わるものではありません）、より多くの追加、より短いメソッド、より単純で単一の責任のクラスを書くのに役立つツールキット、etcetera。ただし、OOPの代わりにはなりません。
OOPを（少なくとも部分的に）置換または追加するのは関数型プログラミングですが、これは実際には異なるプログラミングパラダイムです（ただし、Scalaプログラミング言語などでOOPと混在させることができます）。特に並行性に関しては、不変のデータ構造とOOP開発者を苛立たせる傾向があるあらゆる種類の凝った機能を好みます。
OOPは、多くの状況でデファクトアプローチであると想定されているため、最近はあまり話題になりません。AOPはあらゆる種類の大衆運動として地面から降りることはありません。
既存のAOPシステムをいくつか見てください。それらは、何らかのコードが何らかの形式で記述されているかどうかに依存します。たとえば、Spring AOPは、クラスでメソッドが定義されていることに依存しています。Castle Windsorは、オブジェクト指向言語であるC＃でそれをサポートしています。
理論的にはOOPから構造化プログラミングに切り替えてもAOPを維持できますが、実際にはそれは困難です。何かをサブクラス化し、適切なbefore / afterフィルターを呼び出すために関連するメソッドをオーバーライドし、依存性注入のプロセスでそれを渡すのは簡単です。
静的メソッド呼び出しを書き換えて、ユーザー定義のフィルターを呼び出すように設計されたトランポリンメソッドにルーティングするのに比べると、かなり大変です。
一般的な実装の観点から、AOPにはOOPが必要です。
OOPは確かに特効薬ではありませんが、AOPについても同じことが言えます。コンポーネントベースのデザインをサポートしますが、より壮大なスキームでは、コンポーネントは新しいオブジェクトであり、コンポーネントインターフェイスは基本的にトランザクションのリストであり、真のOOPではありません。
さらにAOPとコンポーネントベースのデザインが貧血データモデルをサポートしています。
http://martinfowler.com/bliki/AnemicDomainModel.html
（私は上記の記事が古いが、驚くほど関連性があることを知っています）
要するに、AOPシステムは今も存続しているということですが、完璧とは言えません。完璧なシステムはありません。