アスペクト指向プログラミング

コンピューティングにおいて、アスペクト指向プログラミング（AOP）は、横断的な関心事を分離することでモジュール性を高めることを目的としたプログラミングパラダイムです。これは、既存のコードを変更することなく、既存のコードに動作（アドバイス）を追加することで実現されます。代わりに、「関数名が 'set 'で始まるすべての関数呼び出しをログに記録する」といった「ポイントカット」仕様によって、どのコードを変更するかを個別に指定します。これにより、ビジネスロジックの中心ではない動作（ログ記録など）を、コア機能のコードを煩雑にすることなくプログラムに追加できます。

AOPは、ソースコードレベルでの関心のモジュール化をサポートするプログラミング手法とツールを含みますが、アスペクト指向ソフトウェア開発は、エンジニアリング分野全体を指します。

アスペクト指向プログラミングでは、プログラムロジックをまとまりのある機能領域（いわゆる関心事）に分解します。ほぼすべてのプログラミングパラダイムは、これらの関心事を実装、抽象化、構成するために使用できる抽象化（関数、プロシージャ、モジュール、クラス、メソッドなど）を提供することで、関心事をある程度グループ化し、独立したエンティティにカプセル化することをサポートしています。しかし、プログラム内で複数の抽象化をまたぐ関心事もあり、これらの実装方法では対応できません。このような関心事は、横断的関心事または水平的関心事と呼ばれます。

ロギングは、システム全体のログ記録対象部分すべてに影響を与える必要があるため、横断的な関心事の一例と言えます。したがって、ロギングはログ記録対象となるすべてのクラスとメソッドにまたがります。

すべての AOP 実装には、各関心事を 1 箇所にカプセル化する横断的な式がいくつかあります。実装間の違いは、提供される構成要素のパワー、安全性、および使いやすさにあります。たとえば、型安全性やデバッグのサポートがほとんどない、限定的な形式の横断的表現方法を指定するインターセプターがあります。AspectJにはそのような式が多数あり、それらをアスペクトと呼ばれる特別なクラスにカプセル化しています。たとえば、アスペクトは、ポイントカットと呼ばれる定量化またはクエリ (特定のジョイン ポイントが一致するかどうかを検出する) で指定されたさまざまなジョイン ポイント(プログラム内のポイント) でアドバイス(追加の動作) を適用することにより、ベースコード(プログラムのアスペクト以外の部分) の動作を変更できます。アスペクトは、メンバーや親を追加するなど、他のクラスにバイナリ互換性のある構造変更を行うこともできます。

AOPにはいくつかの直接的な前身があります: ^{[ 1 ]}リフレクションとメタオブジェクトプロトコル、主体指向プログラミング、コンポジションフィルタ、および適応プログラミング。^{[ 2 ]}

グレゴール・キザレス氏とゼロックスPARCの同僚たちは、AOPの明確な概念を開発し、それに続いてJava用のAOP拡張機能であるAspectJを開発しました。IBMの研究チームは、言語設計アプローチよりもツールアプローチを追求し、2001年にHyper/JとConcern Manipulation Environmentを提案しましたが、これらは広く普及していません。

この記事の例では、AspectJを使用しています。

Microsoft Transaction Server はAOP の最初の主要なアプリケーションと考えられており、それに続いてEnterprise JavaBeansが登場しました。^{[ 3 ] [ 4 ]}

通常、アスペクトはコードとして散在したり絡み合ったりするため、理解や保守が困難になります。散在の原因は、ログ記録などの機能が、その機能を使用する可能性のある、互いに無関係な複数の機能に分散していることです。これらの機能は、全く異なるシステムで動作していたり​​、異なる言語で記述されていたりする場合もあります。そのため、ログ記録を変更するには、影響を受けるすべてのモジュールを変更する必要が生じる可能性があります。アスペクトは、それが表現されるシステムのメインライン機能だけでなく、アスペクト同士でも絡み合います。したがって、1つの懸念事項を変更するには、絡み合ったすべての懸念事項を理解するか、変更の影響を推測できる何らかの手段が必要となります。

例えば、ある口座から別の口座へ金額を送金する、概念的には非常にシンプルな方法を持つ銀行アプリケーションを考えてみましょう。Javaでのそのような例は次のようになります。

sealed class BankingException extends Exception permits InsufficientFundsException , UnauthorisedUserException { // ... }public class Bank { public void transfer ( Account fromAcc , Account toAcc , int amount ) throws BankingException { if ( fromAcc . getBalance () < amount ) { throw new InsufficientFundsException (); }fromAcc.withdraw ( amount ) ; toAcc.deposit ( amount ) ; } }​​

しかし、この転送方法では、展開されたアプリケーションが必要とするいくつかの考慮事項が見落とされています。例えば、現在のユーザーがこの操作を実行する権限を持っていることを確認すること、偶発的なデータ損失を防ぐためにデータベーストランザクションをカプセル化すること、診断目的で操作をログに記録することなどです。

これらの新たな懸念事項をすべて盛り込んだバージョンは、おそらく次のようになるでしょう。

import java.util.logging.* ;sealed class BankingException extends Exception permits InsufficientFundsException , UnauthorisedUserException { // ... }public class Bank { private static final Logger logger ; private final Database database ; public void transfer ( Account fromAcc , Account toAcc , int amount , User user ) throws BankingException { logger.info ( "送金中..." ) ; if ( ! isUserAuthorised ( user , fromAcc )) { logger.log ( Level.WARNING , "ユーザーに権限がありません。" ) ; throw new UnauthorisedUserException (); } if ( fromAcc.getBalance ( ) < amount ) { logger.log ( Level.WARNING , "残高不足です。" ) ; throw new InsufficientFundsException ( ); }fromAcc.withdraw ( amount ) ; toAcc.deposit ( amount ) ;​​database.commitChanges ( ) ; // アトミック操作。logger.log ( Level.INFO , "トランザクション成功。" ) ; } }

この例では、他の関心事が基本的な機能（ビジネスロジックの懸念事項と呼ばれることもある）と絡み合っています。トランザクション、セキュリティ、ログ記録はすべて、横断的な懸念事項の例です。

では、アプリケーションのセキュリティに関する考慮事項を突然変更する必要が生じた場合を考えてみましょう。プログラムの現在のバージョンでは、セキュリティ関連の操作は多数のメソッドに分散しており、そのような変更には多大な労力が必要となります。

AOPは、プログラマが横断的な関心事をアスペクトと呼ばれる独立したモジュールで表現できるようにすることで、この問題を解決しようとします。アスペクトには、アドバイス（プログラム内の特定のポイントに結び付けられたコード）と型間宣言（他のクラスに追加される構造メンバー）を含めることができます。たとえば、セキュリティモジュールには、銀行口座にアクセスする前にセキュリティチェックを実行するアドバイスを含めることができます。ポイントカットは、銀行口座にアクセスできるタイミング（ジョインポイント）を定義し、アドバイス本体のコードは、セキュリティチェックの実装方法を定義します。このようにして、チェックとアクセスポイントの両方を1か所で管理できます。さらに、優れたポイントカットは、後々のプログラムの変更を予測できるため、別の開発者が銀行口座にアクセスする新しいメソッドを作成した場合、その新しいメソッドが実行されると、アドバイスが適用されます。

上記の例では、アスペクトでログ記録を実装します。

アスペクトロガー{ロガーロガー;void Bank.transfer ( Account fromAcc , Account toAcc , int amount , User user ) { logger.info ( "送金中... " ) ; }void Bank.getMoneyBack ( User user , int transactionId ) { logger.info ( "ユーザーが返金を要求しました。" ) ; }// その他の横断的コード。}

AOPはデバッグツールまたはユーザーレベルのツールと考えることができます。アドバイスは、関数を変更できない場合（ユーザーレベル）^{[ 5 ]}、または本番コードで関数を変更したくない場合（デバッグ）に限定して使用する必要があります。

アスペクト指向言語のアドバイス関連コンポーネントは、ジョイントポイントモデル（JPM）を定義します。JPMは次の3つのことを定義します。

1. アドバイスが実行可能な場合、これらはジョインポイントと呼ばれます。これは、実行中のプログラム内で、追加の動作を効果的に結合できるポイントだからです。ジョインポイントが有用であるためには、通常のプログラマーがアクセス可能で理解できる必要があります。また、アスペクトの安定性を維持するために、プログラムの些細な変更に対しても安定している必要があります。多くのAOP実装では、メソッドの実行とフィールド参照をジョインポイントとしてサポートしています。
2. 結合点を指定（または定量化）する方法をポイントカットと呼びます。ポイントカットは、指定された結合点が一致するかどうかを判定します。最も有用なポイントカット言語は、基本言語と同様の構文を使用し（例えば、AspectJはJavaシグネチャを使用）、命名と組み合わせによって再利用を可能にします。
3. ジョインポイントで実行するコードを指定する手段。AspectJではこれをアドバイスと呼び、ジョインポイントの前、後、周辺で実行できます。一部の実装では、別のクラスのアスペクトでメソッドを定義することもサポートしています。

ジョイントポイントモデルは、公開されているジョイントポイント、ジョイントポイントの指定方法、ジョイントポイントで許可されている操作、および表現可能な構造的拡張機能に基づいて比較できます。

aspect DisplayUpdate { void Point . acceptVisitor ( Visitor v ) { v . visit ( this ); } // その他の横断的コード... }

AOPプログラムは、基盤となる言語や環境に応じて、他のプログラムに2つの異なる方法で影響を与える可能性があります。

1. 結合されたプログラムが生成され、それは元の言語で有効であり、最終的なインタプリタにとっては通常のプログラムと区別がつかない。
2. 最終的なインタプリタまたは環境は、AOP機能を理解し実装できるように更新されます。

環境変更の難しさから、ほとんどの実装では、ウィービングと呼ばれるプログラム変換手法を用いて互換性のある組み合わせプログラムを生成します。アスペクトウィーバーは、アスペクト指向コードを読み込み、アスペクトを統合した適切なオブジェクト指向コードを生成します。同じAOP言語でも様々なウィービング手法で実装できるため、言語のセマンティクスをウィービングの実装方法だけで判断すべきではありません。組み合わせ方法によって影響を受けるのは、実装の速度と展開の容易さだけです。

システムは、プログラムのソースファイルへのアクセスを必要とするプリプロセッサを使用して、ソースレベルのウィービングを実装できます（C++ は当初CFrontで実装されていました）。しかし、Java の明確に定義されたバイナリ形式により、バイトコードウィーバーは .class ファイル形式のあらゆる Java プログラムで動作できます。バイトコードウィーバーは、ビルドプロセス中、またはウィーブモデルがクラスごとの場合はクラスロード中にデプロイできます。AspectJは2001 年にソースレベルのウィービングから始まり、2002 年にクラスごとのバイトコードウィーバーを提供し、2005 年にAspectWerkzを統合した後は、高度なロード時サポートを提供するようになりました。

実行時にプログラムを結合するソリューションは、プログラマの分離モデルを維持するために、それらを適切に分離するビューを提供する必要があります。Java のバイトコードによる複数ソースファイルのサポートにより、デバッガはソースエディタで適切に結合された .class ファイルをステップ実行できます。ただし、一部のサードパーティ製逆コンパイラは、サポートされているすべてのバイトコード形式ではなく、Javac によって生成されたコードを想定しているため、結合されたコードを処理できません (下記の§ 批判も参照)。

デプロイ時のウィービングは別のアプローチを提供します。^{[ 6 ]}これは基本的にポストプロセスを意味しますが、生成されたコードにパッチを適用するのではなく、このウィービングアプローチでは既存のクラスをサブクラス化して、メソッドのオーバーライドによって変更を導入します。既存のクラスは実行時にも変更されず、開発中はデバッガやプロファイラなどの既存のツールをすべて使用できます。同様のアプローチは、 IBMのWebSphereなど、多くのJava EEアプリケーションサーバーの実装ですでに実証されています。

アスペクトはオブジェクト指向プログラミングとリフレクティブプログラミングから生まれました。AOP言語はメタオブジェクトプロトコルと似た機能を持ちますが、より制限されています。アスペクトは、サブジェクト、ミックスイン、デリゲーションなどのプログラミング概念と密接に関連しています。アスペクト指向プログラミングパラダイムを使用する他の方法としては、コンポジションフィルタとハイパースライスアプローチがあります。少なくとも1970年代以降、開発者はAOPの実装方法の一部に似たインターセプションとディスパッチパッチングの形式を使用してきましたが、これらは横断的な仕様が1か所で提供する意味論を持っていませんでした。

設計者は、 C#の部分型など、コードの分離を実現するための代替手段を検討してきたが、そのようなアプローチには、1 つの宣言文でコードの複数の結合点に到達できるような量化メカニズムが欠けている。

一見無関係に思えるかもしれませんが、テストにおいてモックやスタブを使用するには、アラウンドアドバイスなどのAOP（アスペクト指向プログラミング）の手法を用いる必要があります。ここでは、テストの目的上、連携するオブジェクトは横断的な関心事となります。そのため、様々なモックオブジェクトフレームワークがこれらの機能を提供しています。例えば、あるプロセスがサービスを呼び出して残高を取得するとします。プロセスのテストにおいては、残高がどこから来るかは重要ではなく、プロセスが要件に従って残高を使用することだけが重要です。

プログラマーはエラーを防ぐためにコードを読み、理解できる必要があります。^{[ 9 ]} 適切な教育を受けていても、プログラムの静的構造と動的フローの両方を視覚化するための適切なサポートがなければ、横断的関心事を理解するのは難しい場合があります。^{[ 10 ]} 2002 年以降、AspectJ は横断的関心事の視覚化をサポートする IDE プラグインの提供を開始しました。これらの機能、およびアスペクト コード アシストとリファクタリングは、現在では一般的です。

AOPの強力な機能を考えると、横断的関心の表現において論理的な誤りを犯すと、プログラム全体に影響を及ぼす可能性があります。逆に、別のプログラマーが、メソッド名の変更や移動などによって、アスペクト作成者が想定していなかった方法でプログラムの結合点を変更し、予期せぬ結果を招くこともあります。横断的関心をモジュール化する利点の1つは、1人のプログラマーがシステム全体に容易に影響を与えられることです。結果として、このような問題は、特定の障害に対する責任をめぐる2人以上の開発者間の対立として現れます。AOPは、アスペクトのみを変更すれば済むため、これらの問題の解決を迅速化できます。AOPを使用しない場合、同様の問題はより広範囲に及ぶ可能性があります。

AOP の効果に対する最も基本的な批判は、制御フローが不明瞭になることであり、悪名高いGOTOステートメントよりも悪いだけでなく、冗談のようなCOME FROMステートメントと非常によく似ているというものです。^{[ 10 ]} AOP の多くの定義の基本である適用の無知性(問題のコードにはアドバイスが適用されるという兆候がなく、代わりにポイントカットで指定されます) は、明示的なメソッド呼び出しとは対照的に、アドバイスが見えないことを意味します。^{[ 10 ] [ 11 ]}例えば、COME FROM プログラムを比較してください。^{[ 10 ]}

5入力X 10出力'結果は:' 15出力X 20 10から来る25 X = X * X 30戻り値

同様の意味を持つAOPフラグメントと共に：

main () { input x print ( result ( x )) }input result ( int x ) { return x } around ( int x ): call ( result ( int )) && args ( x ) { int temp = proceed ( x ) return temp * temp }

実際、ポイントカットは実行時の条件に依存する可能性があり、静的に決定論的ではない場合があります。静的解析と、どの助言が一致する可能性があるかを示すIDEのサポートによって、この問題は軽減できますが、完全に解決することはできません。

一般的な批判としては、AOP は「モジュール性とコード構造の両方を改善する」と謳っているが、実際にはこれらの目標を損ない、「プログラムの独立した開発と理解可能性」を阻害するというものがある。^{[ 12 ]}具体的には、ポイントカットによる定量化はモジュール性を破壊する。「一般的に、アスペクト指向プログラムの動的実行について推論するには、プログラム全体の知識が必要となる。」^{[ 13 ]}さらに、その目標（横断的関心のモジュール化）はよく理解されているものの、実際の定義は不明確であり、他の確立された手法と明確に区​​別されていない。^{[ 12 ]}横断的関心は互いに交差する可能性があり、順序付けなどの解決メカニズムが必要となる。^{[ 12 ]}実際、アスペクトはそれ自身に適用できるため、嘘つきのパラドックスなどの問題が生じる。^{[ 14 ]}

技術的な批判としては、ポイントカットの定量化（アドバイスが実行される場所を定義すること）が「プログラムの変更に極めて敏感」であり、これは脆弱なポイントカット問題として知られているという点が挙げられる。^{[ 12 ]}ポイントカットの問題は解決不可能とみなされている。ポイントカットの定量化を明示的な注釈に置き換えると、属性指向プログラミングが得られるが、これは単に明示的なサブルーチン呼び出しであり、AOPが解決するように設計された散逸という同じ問題を抱えている。^{[ 12 ]}

多くのプログラミング言語は、言語内部または外部ライブラリとしてAOPを実装しており、以下はその例です。

• .NETフレームワーク言語（C#、Visual Basic（.NET）（VB.NET））^{[ 15 ]}
  • PostSharpは商用AOP実装であり、無料版もあるが機能制限がある。
  • Unityは、データアクセス、セキュリティ、ログ記録、例外処理など、プログラミングの中核分野における実績のある手法を容易にするためのAPIを提供します。
  • AspectDNは、.NET実行可能ファイルに直接アスペクトを織り込むことを可能にするAOPの実装です。
• ActionScript ^{[ 16 ]}
• エイダ^{[ 17 ]}
• AutoHotkey ^{[ 18 ]}
• C、C++ ^{[ 19 ]}
• COBOL ^{[ 20 ]}
• Cocoa Objective-Cフレームワーク^{[ 21 ]}
• ColdFusion ^{[ 22 ]}
• Common Lisp ^{[ 23 ]}
• デルフィ^{[ 24 ] [ 25 ] [ 26 ]}
• デルファイ・プリズム^{[ 27 ]}
• e（IEEE 1647）
• Emacs Lisp ^{[ 28 ]}
• グルーヴィー
• Haskell ^{[ 29 ]}
• Java ^{[ 30 ]}
  • アスペクトJ
• JavaScript ^{[ 31 ]}
• Logtalk ^{[ 32 ]}
• Lua ^{[ 33 ]}
• 作成^{[ 34 ]}
• Matlab ^{[ 35 ]}
• ML ^{[ 36 ]}
• ネメルレ^{[ 37 ]}
• Perl ^{[ 38 ]}
• PHP ^{[ 39 ]}
• プロローグ^{[ 40 ]}
• Python ^{[ 41 ]}
• ラケット^{[ 42 ]}
• ルビー^{[ 43 ] [ 44 ] [ 45 ]}
• スクイークスモールトーク^{[ 46 ] [ 47 ]}
• UML 2.0 ^{[ 48 ]}
• XML ^{[ 49 ]}

• 分散AOP
• 属性文法とは、関数型プログラミング言語におけるアスペクト指向プログラミングに使用できる形式体系である。
• プログラミングパラダイム
• 主題指向プログラミング（アスペクト指向プログラミングの代替案）
• 役割指向プログラミングは、アスペクト指向プログラミングの代替手段である。
• 述語ディスパッチは、アスペクト指向プログラミングの古い代替手段である。
• 実行可能なUML
• 装飾パターン
• ドメイン駆動設計

• Kiczales, G. ; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, JM; Irwin, J. (1997).アスペクト指向プログラミング(PDF) . ECOOP'97.第11回欧州オブジェクト指向プログラミング会議議事録. Lecture Notes in Computer Science (LNCS). Vol. 1241.  pp. 220–242 . CiteSeerX 10.1.1.115.8660 . doi : 10.1007/BFb0053381 . ISBN   3-540-63089-9。この論文は、AOPに関する権威ある参考文献として一般的に認められている。
• ロバート・E・フィルマン、ツィラ・エルラッド、シボーン・クラーク、メフメト・アクシット（2004）。アスペクト指向ソフトウェア開発。アディソン・ウェスリー。ISBN 978-0-321-21976-3。
• ルノー・ポーラック、リオネル・サンチュリエ、ジャン＝フィリップ・リタイレ（2005）。J2EE開発のためのAOPの基礎。Apress。ISBN 978-1-59059-507-7。
• ラダッド、ラムニバス（2003）。『AspectJ in Action: Practical Aspect-Oriented Programming』 。マニング。ISBN 978-1-930110-93-9。
• ジェイコブソン、イヴァル；パンウェイ・ン（2005）。アスペクト指向ソフトウェア開発とユースケース。アディソン・ウェスリー。ISBN 978-0-321-26888-4。
• アスペクト指向ソフトウェア開発とPHP、ドミトリー・シェイコ、2006年
• シボーン・クラーク＆エリサ・バニアサド（2005）。アスペクト指向分析と設計：テーマアプローチ。アディソン・ウェスリー。ISBN 978-0-321-24674-5。
• Raghu Yedduladoddi (2009).アスペクト指向ソフトウェア開発：UML設計モデルの構成へのアプローチ. VDM. ISBN 978-3-639-12084-4。
• 「グラフベースのカスタマイズを用いた適応型オブジェクト指向プログラミング」 – Lieberherr、Silva-Lepe他– 1994年
• Zambrano Polo y La Borda, Arturo Federico (2013年6月5日). 「産業環境における側面間の相互作用への対応：経験、問題、および解決策」 : 159. doi : 10.35537/10915/35861 . 2014年5月30日取得。{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）
• Wijesuriya, Viraj Brian (2016-08-30)アスペクト指向開発、講義ノート、コロンボ大学コンピューティング学部、スリランカ
• Groves, Matthew D. (2013). AOP in .NET . Manning. ISBN 9781617291142。

• エリック・ボデン氏による.NETフレームワークにおけるAOPツールのリスト
• アスペクト指向ソフトウェア開発、AOPに関する年次会議
• AspectJプログラミングガイド
• AspectJ 用の AspectBench コンパイラは、別の Java 実装です。
• IBM developerWorksのAOPに関する一連の記事
• ラダッド、ラムニバス（2002年1月18日）。「私の AOP が欲しいです!、パート 1」。JavaWorld。2020 年7 月 20 日に取得。アスペクト指向プログラミングとAspectJの基礎に関する詳細な一連の記事
• アスペクト指向プログラミングとは？、RemObjects Tacoによる入門編
• 制約仕様アスペクトウィーバー
• アスペクト指向プログラミングとオブジェクト指向プログラミング：どちらの手法をいつ使うべきか？ （2021年4月15日、 Wayback Machineにアーカイブ済み）
• グレゴール・キザレス教授（コンピュータサイエンス）によるAOPの説明（動画、57分）。
• COBOLにおけるアスペクト指向プログラミング（ 2008年12月17日にWayback Machineにアーカイブ済み）
• Springフレームワークを用いたJavaにおけるアスペクト指向プログラミング
• .NETにおけるAOPメソッドに関するWiki
• ビジネスプロセスモデリングの初期段階（BPMNのためのアスペクト指向言語）
• Spring AOPとAspectJの紹介
• ビルケント大学におけるAOSD大学院コース
• AOP入門 – ソフトウェアエンジニアリングラジオポッドキャスト第106回
• Szilveszter Molnar による AOP の Objective-C 実装
• マヌエル・ゲベレ著『iOSおよびOS Xのためのアスペクト指向プログラミング』
• DevExpress MVVMフレームワーク。POCOビューモデル入門