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

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

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

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

ロギングは横断的な関心事の例です。ロギング戦略は、システムのログに記録されるすべての部分に影響を与える必要があるためです。したがって、ロギングは、ログに記録されるすべてのクラスとメソッドを横断的に処理します。

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

AOPには、A1とA2という直接的な前身があります。^[1] リフレクションとメタオブジェクトプロトコル、サブジェクト指向プログラミング、コンポジションフィルタ、アダプティブプログラミング。^[2]

Xerox PARCのGregor Kiczales氏とその同僚は、AOP の明確な概念を開発し、それに続いてJava のAspectJ AOP 拡張を開発しました。IBM の研究チームは、言語設計アプローチよりもツール アプローチを追求し、2001 年にHyper/JとConcern Manipulation Environment を提案しましたが、これらは広く使用されることはありませんでした。

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

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

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

例えば、ある口座から別の口座に金額を送金するという概念的には非常に単純な方法を持つ銀行アプリケーションを考えてみましょう。^[5]

void transfer ( Account fromAcc 、Account toAcc 、int amount )は例外をスローします{ if ( fromAcc . getBalance () < amount ) throw new InsufficientFundsException ();         
     
        

  fromAcc.withdraw (金額) ; toAcc.deposit (金額) ; }​​
  

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

これらすべての新しい懸念事項を考慮したバージョンは次のようになります。

void transfer ( Account fromAcc 、Account toAcc 、int amount 、User user 、Logger logger 、Database database ) throws Exception { logger . info ( "送金中..." ); if ( ! isUserAuthorised ( user 、fromAcc )) { logger . info ( "ユーザーに権限がありません。" ); throw new UnauthorisedUserException (); } if ( fromAcc . getBalance () < amount ) { logger . info ( "資金が不足しています。" ); throw new InsufficientFundsException (); }        
          
  
  
     
    
      
  
  
      
    
      
  

  fromAcc.withdraw (金額) ; toAcc.deposit (金額) ;​​
  

  database . commitChanges (); // アトミック操作。  

  logger . info ( "トランザクションは成功しました。" ); 
}

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

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

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

したがって、アスペクトでログ記録を実装する上記の例では、次のようになります。

aspect Logger { void Bank . transfer ( Account fromAcc 、Account toAcc 、int amount 、User user 、Logger logger ) { logger . info ( "送金中..." ); }  
              
    
  

  void Bank.getMoneyBack ( User user , int transactionId , Logger logger ) { logger.info ( "ユーザーが返金を要求しました。" ) ; }        
    
  

  // その他の横断的なコード。
}

AOPはデバッグツールまたはユーザーレベルツールとして考えることができます。アドバイスは、関数を変更できない場合（ユーザーレベル）^[6]、または製品コードで関数を変更したくない場合（デバッグ）にのみ使用してください。

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

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

結合ポイント モデルは、公開される結合ポイント、結合ポイントの指定方法、結合ポイントで許可される操作、および表現できる構造強化に基づいて比較できます。

JPM には他にも種類があります。すべてのアドバイス言語は、JPM に基づいて定義できます。たとえば、UMLの仮想的なアスペクト言語には、次のような JPM があります。

• 結合ポイントはすべてモデル要素です。
• ポイントカットは、モデル要素を組み合わせたブール式です。
• これらのポイントでの影響の平均は、一致するすべての結合ポイントを視覚化したものです。

インタータイプ宣言は、モジュールの構造に影響を与える横断的な関心事を表現する方法を提供します。オープン クラスや拡張メソッドとも呼ばれ、これによりプログラマーは 1 か所で別のクラスのメンバーまたは親を宣言し、通常は 1 つの側面の関心事に関連するすべてのコードを結合できます。たとえば、プログラマーがビジターを使用して横断的な表示更新の関心事を実装した場合、ビジター パターンを使用したインタータイプ宣言は、AspectJ では次のようになります。

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

このコード スニペットは、クラスacceptVisitorにメソッドを追加しますPoint。

AOP 実装が常にすべてのクライアントを制御できる場合を除き、既存のクラスのクライアントが引き続き動作するように、構造上の追加は元のクラスと互換性がある必要があります。

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

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

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

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

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

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

アスペクト指向プログラミングで使用される標準的な用語には次のようなものがあります。

横断的な懸念

オブジェクト指向モデルのほとんどのクラスは単一の特定の機能を実行しますが、他のクラスと共通の二次要件を共有することがよくあります。たとえば、スレッドがメソッドに出入りするたびに、データアクセス層内のクラスとUI層のクラスにログ記録を追加する必要がある場合があります。さらに、アクセス制御^[8]や情報フロー制御^[9]などのセキュリティに関連する懸念事項もあります。各クラスの主要な機能は非常に異なりますが、二次機能を実行するために必要なコードは多くの場合同一です。

アドバイス

これは、既存のモデルに適用する追加コードです。この例では、スレッドがメソッドに入るときやメソッ​​ドを終了するときに適用するログ記録コードです。

ポイントカット

これは、横断的関心事を適用する必要があるアプリケーションの実行ポイントを指します。この例では、スレッドがメソッドに入るときにポイントカットに到達し、スレッドがメソッドを終了するときに別のポイントカットに到達します。

側面

ポイントカットとアドバイスの組み合わせはアスペクトと呼ばれます。上記の例では、ポイントカットを定義して適切なアドバイスを提供することで、アプリケーションにロギング アスペクトを追加します。

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

設計者は、 C#の部分型など、コードの分離を実現する別の方法を検討してきましたが、このようなアプローチには、1 つの宣言文でコードの複数の結合ポイントに到達できる定量化メカニズムが欠けています。^{[引用が必要]}

関係ないと思われるかもしれませんが、テストでは、モックやスタブを使用するには、アラウンド アドバイスなどの AOP テクニックを使用する必要があります。ここで、連携するオブジェクトはテストの目的、つまり横断的な関心事です。したがって、さまざまなモック オブジェクト フレームワークがこれらの機能を提供します。たとえば、プロセスは残高を取得するためにサービスを呼び出します。プロセスのテストでは、金額がどこから来るかは重要ではなく、プロセスが要件に従って残高を使用することだけが重要です。^{[引用が必要]}

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

AOP の威力を考えると、横断的関係を表現する際に論理的な誤りを犯すと、広範囲にわたるプログラム障害につながる可能性があります。逆に、別のプログラマーが、メソッドの名前変更や移動などにより、アスペクトの作成者が予期していなかった方法でプログラム内の結合ポイントを変更し、予期しない結果をもたらす可能性があります。横断的関係をモジュール化する利点の 1 つは、1 人のプログラマーがシステム全体に簡単に影響を与えることができることです。その結果、このような問題は、特定の障害に対する 2 人以上の開発者間の責任の衝突として現れます。AOP では、アスペクトを変更するだけで済むため、これらの問題の解決を迅速化できます。AOP がなければ、対応する問題ははるかに広範囲に及ぶ可能性があります。^{[引用が必要]}

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

 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 は「モジュール性とコード構造の両方」を改善すると主張しているというものですが、一部の人は、AOP はむしろこれらの目標を損ない、「プログラムの独立した開発と理解可能性」を妨げていると反論しています。 ^[13]具体的には、ポイントカットによる定量化はモジュール性を破壊します。「一般に、アスペクト指向プログラムの動的実行について推論するには、プログラム全体の知識が必要です。」^[14]さらに、その目標 (横断的関心事をモジュール化すること) はよく理解されていますが、実際の定義は不明瞭であり、他の確立された手法と明確に区​​別されていません。^[13]横断的関心事は相互に横断する可能性があり、順序付けなどの何らかの解決メカニズムが必要です。^{[13]実際、アスペクトはそれ自体に適用され、}嘘つきのパラドックスなどの問題を引き起こす可能性があります。^[15]

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

多くのプログラミング言語では、言語内または外部ライブラリとして AOP が実装されています。

• .NETフレームワーク言語（C#、Visual Basic（.NET）（VB.NET））^[16]
  • PostSharp は、無料だが制限付きのエディションを備えた商用 AOP 実装です。
  • Unity は、データ アクセス、セキュリティ、ログ記録、例外処理などのプログラミングのコア領域における実証済みのプラクティスを促進する API を提供します。
  • AspectDN は、.NET 実行可能ファイルに直接アスペクトを組み込むことを可能にする AOP 実装です。
• アクションスクリプト^[17]
• エイダ^[18]
• オートホットキー^[19]
• C、C++ ^[20]
• コボル^[21]
• Cocoa Objective - Cフレームワーク^[22]
• コールドフュージョン^[23]
• コモンリスプ^[24]
• デルファイ^{[25] [26] [27]}
• デルファイプリズム^[28]
• （ IEEE 1647）
• エマックス・リスプ^[29]
• グルーヴィー
• ハスケル^[30]
• ジャワ語^[31]
  • アスペクトJ
• JavaScript ^[32]
• ログトーク^[33]
• ルア^[34]
• 作る^[35]
• マトラボ^[36]
• ML ^[37]
• ネメルレ^[38]
• パール^[39]
• フィリピン^[40]
• プロローグ^[41]
• パイソン^[42]
• ラケット^[43]
• ルビー^{[44] [45] [46]}
• スクイーク ・スモールトーク^{[47] [48]}
• UML 2.0 ^[49]
• テキスト^[50]

• 分散AOP
• 属性文法、関数型プログラミング言語におけるアスペクト指向プログラミングに使用できる形式論
• プログラミングパラダイム
• アスペクト指向プログラミングの代替となるサブジェクト指向プログラミング
• アスペクト指向プログラミングの代替となるロール指向プログラミング
• 述語ディスパッチ、アスペクト指向プログラミングの古い代替手段
• 実行可能なUML
• デコレータパターン
• ドメイン駆動設計

• Kiczales, G. ; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, JM; Irwin, J. (1997). アスペクト指向プログラミング(PDF) . ECOOP '97.第 11 回ヨーロッパオブジェクト指向プログラミング会議の議事録.コンピュータサイエンスの講義ノート(LNCS). 第 1241 巻. pp. 220–242. CiteSeerX  10.1.1.115.8660 . doi :10.1007/BFb0053381. ISBN 3-540-63089-9。一般に AOP の権威ある参考文献とみなされている論文。
• Robert E. Filman、Tzilla Elrad、Siobhán Clarke、Mehmet Aksit (2004)。アスペクト指向ソフトウェア開発。Addison- Wesley。ISBN 978-0-321-21976-3。
• Renaud Pawlak、Lionel Seinturier、Jean-Philippe Retaillé (2005)。J2EE開発のための AOP の基礎。Apress。ISBN 978-1-59059-507-7。
• Laddad, Ramnivas (2003)。『AspectJ の実践: 実践的なアスペクト指向プログラミング』。Manning。ISBN 978-1-930110-93-9。
• Jacobson, Ivar ; Pan-Wei Ng (2005)。ユースケースによるアスペクト指向ソフトウェア開発。Addison- Wesley。ISBN 978-0-321-26888-4。
• アスペクト指向ソフトウェア開発と PHP、Dmitry Sheiko、2006 年
• Siobhán Clarke & Elisa Baniassad (2005)。アスペクト指向分析と設計: テーマアプローチ。Addison-Wesley。ISBN 978-0-321-24674-5。
• Raghu Yedduladoddi (2009)。アスペクト指向ソフトウェア開発: UML 設計モデルの作成アプローチ。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。

• Eric Boddenによる .NET フレームワークの AOP ツールのリスト
• アスペクト指向ソフトウェア開発、AOP に関する年次会議
• AspectJ プログラミング ガイド
• AspectJ用のAspectBenchコンパイラ、別のJava実装
• AOP に関する IBM developerWorks の記事シリーズ
• ラダッド、ラムニバス（2002年1月18日）。 「私の AOP! が欲しいです、パート 1」。JavaWorld。2020 年7 月 20 日に取得。アスペクト指向プログラミングとAspectJの基礎に関する詳細な記事シリーズ
• アスペクト指向プログラミングとは何か？RemObjects Taco による入門
• 制約仕様アスペクトウィーバー
• アスペクト指向プログラミングとオブジェクト指向プログラミング: どちらの手法をいつ使うか? 2021 年 4 月 15 日、Wayback Machineにアーカイブ
• コンピュータサイエンス教授の Gregor Kiczales による AOP の説明、ビデオ 57 分。
• COBOL におけるアスペクト指向プログラミング 2008-12-17 にWayback Machineでアーカイブ
• Spring Framework を使用した Java のアスペクト指向プログラミング
• .NET 上の AOP メソッドに特化した Wiki
• ビジネス プロセス モデリングの初期の側面 (BPMN のアスペクト指向言語)
• Spring AOP と AspectJ の紹介
• ビルケント大学のAOSD大学院コース
• AOP 入門 – ソフトウェア エンジニアリング ラジオ ポッドキャスト エピソード 106
• Szilveszter Molnar による AOP の Objective-C 実装
• iOS および OS X 向けアスペクト指向プログラミング (Manuel Gebele 著)
• DevExpress MVVM フレームワーク。POCO ViewModel の紹介