 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| AOPの適用範囲 | ||||||||||||
|
アスペクト指向についての質問に、「いったい何の処理を分離してアスペクトとすればよいのか？」というものがあります。 これについての回答は様々あると思いますが、筆者は「システム開発をするときにはよく基盤チームを作りますよね。その基盤チームが管理できる処理であればアスペクトとして分離できると思います」と回答します。 基盤チームが管理できる処理としては先ほどあげたトレースログ処理やトランザクション管理、例外処理、ログイン（セキュリティ）処理などがあると思います。そのような処理は基盤チームが開発当初から分離／管理しておいて、開発チームが作成した処理に付け加えるのに向いています。 では、ビジネスロジックはどうでしょう。基盤チームが管理できるでしょうか。 通常、ビジネスロジックは開発チームが作り、基盤チームはビジネスロジックには無関係でいることが多いと思います。そもそも規模が大きくなれば複数の開発チームが分担して作成する複雑なビジネスロジックを1つの基盤チームが管理することは難しいでしょう。 よって、ビジネスロジックはアスペクトとして分離するのには向いていません。もちろん、小規模開発で参加メンバーのコミュニケーションが取りやすいのであれば、どんな処理でも分離して、それで開発しやすいのであれば、なんでもかんでもアスペクトとして処理してもかまわないでしょう。ただし、その場合もメンテナンスを考えると不適切になると思います。 AOPを適用する範囲は、プロジェクトで管理可能な程度に抑える必要があります。 |
||||||||||||
| AOPの用語 | ||||||||||||
|
さて、ここまでAOPについて哲学や思想を排除した形で何ができるのかなどを記述してきましたが、ここからはAOPの知識として、代表的な用語を簡単に説明します。次回以降はSeasar2・SpringのAOPのサンプルを用いて、具体的なイメージはつかんでいただくこととして、今回は各用語の意味を大まかに理解してください。
表1：用語解説
 図1：AOPの要素の関係  図2：Joinpoint  図3：Pointcut さて分離された関心事は、再びソフトウェアの最終的なクラス構造に適用しなくてはいけません。このアスペクトをクラス構造に組み込む処理をWeavingもしくは織り込むと呼んでいます。アスペクトをクラスに織り込ませていくイメージから名づけられたようです。  図4：関心事の分離とWeaving |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
