 |
||||||||||||
|
||||||||||||
| 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| アスペクト指向プログラミング（AOP：Aspect Oriented Programming）とは | ||||||||||||
|
AOPとはアスペクト指向に基づいたプログラミングのことです。しかし「アスペクト指向」や「それに基づいたプログラミング」とは何でしょうか。 今までにAOPについて様々な文献を読んでみたけれど、よく理解できなかったという方もいらっしゃるのではないでしょうか。何を隠そう、筆者も最初はよく理解できませんでした。 でも、それもそのはず、AOPを解説する人の多くは、アスペクト指向の思想や未来を含めて語っているからです。読者の多くは思想や未来はいいから、今の開発現場にAOPを取り入れると何ができるのか、取り入れると何がよいのかなどを知りたいのだと思います。今回はなるべく思想や哲学を除外した形でAOPの疑問に応えていきます（注1）。
※注1：
本連載ではアスペクト指向について用語も含め意訳して記述しています。アスペクト指向について正しく学びたい方は「アスペクト指向入門 千葉滋著 技術評論社」を是非お読みください。
|
||||||||||||
| AOPで何ができるのか | ||||||||||||
|
AOPで何ができるのかを一言でいうと、「元のソースコードに変更を加えずに新たな処理を追加すること」となります。 では、具体的にどのようなことができるのでしょう。まず、リスト1を見てください。 リスト1 |
||||||||||||
public class HelloWorld {
|
||||||||||||
|
リスト1は初学者向けのプログラムとしてよく見かけるHelloWorldクラスです。普通のHelloWorldクラスと異なるのはmainメソッドの中に「System.out.println("HelloWorld!")」がないことです。このHelloWorldクラスを実行するとどうなるでしょうか。 実行した結果がリスト2です。普通に考えればコンソール上には何も表示されませんが、"HelloWold!"と表示されました。 リスト2 |
||||||||||||
>Java HelloWorld
|
||||||||||||
|
リスト2のように普通ではあり得ない結果になるのは、元のソースコードに変更を加えずに新たな処理「System.out.println("HelloWorld!")」を追加しているからです。 このようにAOPでは元のソースコードに手を加えず、新たな処理を追加することができます。追加する処理は「System.out.println("HelloWorld!")」であろうが、トレースログ出力であろうが、トランザクション管理であろうが何でもかまいません。 しかし、それではとばかりに実開発で何でもかんでも後から処理を追加さては管理ができなくて困ってしまいます。何しろ対象ソースコードに書かれていないことまでもが実行されてしまうのですから。 そこで後から追加してもよい処理は、システム内の色々なオブジェクトで共通して利用する処理になります。先ほどの例だと「System.out.println("HelloWorld!")」という処理はシステム内で共通して利用できないため、実開発では追加しては駄目な処理です。トレースログの出力やトランザクション管理などはシステム内で共通して利用できるので後から追加してもよいでしょう。 アスペクト指向ではトレースログの出力とトランザクション管理のように共通で利用でき、元のソースコードを変更せずに追加してもよい処理の総称を「横断的関心事」といい、追加するトレースログ出力やトランザクション管理の処理そのものと、その処理をどこに追加するのかの情報をまとめたものを「Aspect（アスペクト）」といいます。 |
||||||||||||
| AOPを使うと何がよいのか | ||||||||||||
|
では、後から処理を付け加えることのできるAOPを開発現場に適用すると何がよいのでしょうか。一言でいうと、「誤った処理を減らし可読性のよいプログラムを作ることができる」となります。 例えば、例外処理（コラム参照）の方針を複数の開発チームに伝えたにも関わらず、同じExceptionでもチームによって異なった処理や結果的に誤った処理を記述してしまうことがよくあります。 しかしAOPを利用すれば、各チームが作成した処理に後から統一された例外処理を加えることにより、そのような事態を防ぐことができます。先にあげたトレースログ出力もメッセージを統一するという意味では同様の効果があります。また、定型的な例外処理やトレースログ出力、トランザクション管理が記述されていないソースコードはビジネスロジックだけが記述されているので、すっきりとしていて可読性も上がります。 |
||||||||||||
 |
||||||||||||
|
最近の傾向 比較的規模の大きい開発では、開発に参加するすべてのプログラマのレベルを高く保つことは困難だと思います。そのため、Javaをはじめたばかりのプログラマの書いたメソッドによって、スローされるべきExceptionがcatchされ握りつぶされてしまい本来の例外処理までExceptionが届かず、システムに不具合が起きたときの原因追求が困難だったというのはよくある例です。 特にEclipseのようなIDE（統合開発環境）を利用すればExceptionのtry-catch文がないことを警告し、try-catch文のテンプレートなどを自動生成してくれますが、自動生成されたtry-catch文をそのままにしておけばExceptionはそこで握りつぶされてしまいます。 最近の傾向としては、Exceptionを握りつぶされないようにするため、Exceptionは実行時例外（RuntimeException）を継承したものを利用するようにして、開発中は一般の開発者に例外を意識させないようにクラスを実装させ、一部の開発者のみが例外処理をまとめて行うクラスを実装するのが流行になっています。 |
||||||||||||
|
|
||||||||||||
|
1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
