アスペクト指向プログラミング以外の横断的関心事にはどのような選択肢がありますか？
アスペクト指向プログラミングは、分野横断的な懸念に対処することを約束しますが、まだ完全には販売されていません。この問題に対処する他の試みはありましたか？
可能であれば、横断的な関心事を個別のモジュールにカプセル化し、依存関係の注入によってアプリ全体で使用することができます。これにより、横断的な関心事の実装をコード全体での使用からある程度切り離すことができます。
ただし、これは常にエレガントに機能するとは限りません。それが人々がAOPのようなもので問題に対処しようとしている理由です。
私がまだ検討していない他の2つのオプション：
モナドと矢印を使った関数型プログラミング
FPでは、他と同様に、横断的な関心事を表します：関数呼び出しで渡すものとして。これを行うのは面倒なので、モナド（または矢印）を使用して非表示にすることができます渡されている余分な情報を取り除きます。
最も一般的なAOPの例はロギングです。モナドでは、メッセージのリストを保持する「ロガー」モナドを作成します。 LoggerMonadを介して実行する機能には、ログメッセージを投稿する機能があります。 Arrowsを使用すると、アプリケーションのデータフロー全体をモデル化し、必要に応じてログルーチンをモデルに組み込むことができます。おもう。矢印はかなり複雑です。
エンティティ/コンポーネントベースのプログラミング
ゲームエンジン用に研究および実験を行っているもの。 OOPのような「オブジェクト」の代わりに、すべてをデータのパケット（コンポーネント）とあるタイプのコンポーネントで動作するサービスのパケットに分解します。コンポーネントは、リレーショナルデータベースのように共通のIDでグループ化され、リンクされたコンポーネントのグループはエンティティです。このようなシステムにロギングを追加するには、新しいロギングサービスを追加し、そこを通過するコンポーネントに基づいてトリガーをトリガーします。
どちらの方法でも、横断的な変更を非常に簡単に行うことができますが、どちらも高レベルのアーキテクチャモデルです。したがって、おそらく最初からそれらを使用する必要があります。理論的には、コンポーネントモデルを既存のOOP=システムに組み込むことができます。言語が十分強力であれば、モナドもそうなる可能性があります。
横断的関心事の問題に取り組む方法はいくつかあります。
より良い設計パターン、イディオム、または抽象化メカニズムを使用する：モジュール化できても、コードは横断的である可能性があります。コードを維持するには、モジュール化できる設計手法を使用するようにリファクタリングする必要があります。そのようなリファクタリングは、異なる種類のクロスカットを導入する可能性がありますが、うまくいけば、どのクロスカットが安定していて、変更される可能性は低いでしょう。
より豊富な言語機能を開発する：クロスカッティングの多くの症状は、より優れた抽象化メカニズムによって解決でき、新しい言語機能が必要になる場合もあります。たとえば、関数型およびオブジェクト指向の機能を含むより高度な言語は、必要がないため、多くのデザインパターンを採用していません。 デザインパターン自体は、いくつかの異なるオブジェクトとクラスの役割を記述しているため、本質的に分野横断的である可能性があることに注意してください。 Javaでは、アスペクト比の代わりにリフレクションを使用できますが、実行時のコストは高くなります。たとえば、リフレクションを使用すると、数行のコードで数百のクラスのビジターパターンをサポートできます。 DJライブラリ Northeasternは、まさにそれを行う1つの反射ソリューションです。 Mixins は、C++（Javaではない）で使用できる強力な手法であり、アスペクトと同じ使用例のいくつかを提供できます。
より良いツールサポートの提供：
grepの使用やリファクタリング操作の実行などの手法は、コードのクロスカットに関連する問題に対処できます。たとえば、インターフェイスで宣言されたメソッドの名前は、プログラムを横断する可能性があります。 （ここでの技術的な違いに注意してください：クロスカットするのは、メソッドの名前であり、メソッドの実装ではありません。）これは通常、IDE名前を使用するコード内のすべての場所を変更するための「名前変更リファクタリング」このように、プログラミング環境が十分に表現力がある場合、言語機能を必要としない可能性があります。ドメイン固有の言語を使用する：AspectJより前に登場した初期のアスペクト言語はドメイン固有であり、スレッドの同期や関数構成を効率的に組み合わせるためのデータフロー分析。これらの言語は実験的なものでしたが、他の方法では横断的であった懸念のモジュール化に非常に成功したようです。
ジェネレーティブプログラミングテクニックを使用する：メタレベルへのステップアップは、アスペクト指向プログラミングの実装テクニックと見なされるかもしれませんが、それはそれを超える十分な領域です単純な側面。生成技法（プログラムが別のプログラムのソースコードを生成する）も、ドメイン固有の言語に関連しています。
これらすべてについて、AOPを学ぶことが適切だと思います。 AOPは、AOP言語を使用していなくても、コードの概念を拡張するのに役立ちます。
一般的にコード要素に宣言型の機能でタグを付ける特に C＃/。NET/Monoの世界の属性システム。
私はAOPの専門家ではありませんが、何年にもわたってそれを読んでいると、それは常に LISPによって提供されるメタプログラミング のより弱い形式のように見えました、特にそのメタオブジェクトプロトコルのような部分。
これは当然のことですが、おそらくグレゴール・キッツァーレスはAMOPの作者の1人であり、後にAspectJ for Javaを書きました。