Springフレームワークの設計思想とAOP：Spring Frameworkで理解するDI（2）

» 2005年11月23日 00時00分公開

[山本大，クロノス]

本記事は2005年に執筆されたものです。Spring、DI、AOP全般の最新情報は＠IT Java Solutuionのカテゴリ「DI×AOP（Spring／Seasarなど）」をご参照ください。

　前回「DI：依存性の注入とは何か？」では、Springフレームワークの簡単なサンプルを通じて「Dependency Injection（依存性の注入、以下DI）」とは何かを解説しました。しかし前回の内容では、Springフレームワークの中核機能の一部分を説明したにすぎません。Springフレームワークはさまざまな機能を提供するフレームワークです。今回はSpringフレームワークの設計思想と、その思想を特徴付ける機能のいくつかを紹介し、Springフレームワークがどのようなフレームワークなのかを紹介します。

Springフレームワークの設計思想

　Springフレームワークの設計思想は、（いまやJavaアーキテクトたちの必読の書といってよい）ロッド・ジョンソン氏の著書『Expert One-on-one J2EE Design and Development（邦題：実践J2EEシステムデザイン）』を読むことで知ることができます。この著書の中でロッド・ジョンソン氏が提案した「IoC（Inversion Of Control）」というデザインパターンが名前を変えて、DIと呼ばれるようになりました。

　そもそもフレームワークとは、特定の領域の問題を解決するための基盤を提供するものです。例えば有名なStrutsならば「画面と画面遷移とビジネスロジックの結び付け（MVC）」を対象領域として扱いますし、以前に連載記事「Hibernateで理解するO／Rマッピング」で紹介したHibernateであれば「リレーショナルデータベースとオブジェクトの結び付け（O／Rマッピング）」を対象領域としています。

　Springフレームワークも特定の対象領域を扱うフレームワークですが、ほかのフレームワークとは少し違った対象領域を扱っています。Springフレームワークの設計思想と対象領域を知るためには、まずフレームワークという概念について詳しく考える必要があります。

フレームワークが提供する「枠組み」と「インフラストラクチャ」

　フレームワークとは直訳すれば「枠組み」ですが、プログラミングのためのフレームワークには、その名前どおりの「枠組み」という役割以外にも「インフラストラクチャを提供する」という役割があります。フレームワークが担うこれら2つの役割を明確にしていくと、Springフレームワークの対象領域が見えてきます。

■フレームワークが提供する「枠組み」とは

　プログラムはコンピュータの上では「何でもできる魔法の道具」ですが、ある程度大きなプログラムになると、その自由さ故にそれぞれの部分がばらばらな構造で出来上がってしまいます。複数の人数で構築する企業アプリケーションになればなおさらです。当然、こういった問題は開発チームのリーダーによる管理やプログラミング時のルールによって解決することもできるのですが、属人的な管理では大変な労力が掛かってしまいます。そこでフレームワークがもたらす「枠組み」が効力を発揮するのです。フレームワークの流儀にのっとってプログラミングすることで、統一されたアーキテクチャを持ったアプリケーションを作ることができるようになります。これが、フレームワークが持つ「枠組み」という役割です。

■フレームワークが提供する「インフラストラクチャ」とは

　フレームワークがプログラミングに与えるメリットには、アプリケーションの構造に一貫性を与える「枠組み」という役割以外にも、開発を効率化するための「インフラストラクチャ」という役割があります。

　インフラストラクチャ（インフラ）とは、基盤となる設備や構造のことを指します。例えば社会のインフラストラクチャといえば「電気・ガス・水道・鉄道・道路」などの社会生活の基盤となる設備や構造をいいます。社会にはインフラストラクチャが存在することで、われわれは自分自身の活動目的である「生活」や「仕事」、「遊び」などに専念することができます。

　プログラミングフレームワークでも同じことがいえます。つまりフレームワークという「インフラストラクチャ」が存在することでプログラマーは本来の目的であるビジネスロジックの開発に専念することができるのです。

図1　フレームワークが提供するインフラストラクチャ

　例えば、Servlet（を含むJ2EE）というフレームワークがなかったらどうなるでしょうか。Webアプリケーションを作るのに、Http用のポートを監視したり、Httpリクエスト情報をプログラミングしやすいように加工したり、Httpへのレスポンスを書き込んだりと、本来実現したい目的以外のプログラミングに手間取ってしまうことになります。

プロジェクト固有のインフラストラクチャ構築を提供

　ServletやStruts、Hibernateのようなインフラストラクチャは、多くのプロジェクトで必要となる汎用的な機能を提供するものですが、個別の開発プロジェクトが用意すべきインフラストラクチャも存在します。例えばビジネスロジックがかかわる処理やプロジェクト固有のアーキテクチャに密接に関係する以下のような処理は、インフラストラクチャとして多くのプロジェクトで必要となる処理でありながら、汎用のフレームワークを組み立てにくい処理です。

重要なビジネスロジックでの処理結果を追跡するための詳細なログを書き出す
特定のタイミング、特定のルールで、オブジェクトをキャッシュする
特定のユーザー以外は、オブジェクトのメソッドを呼び出せないようにする

　こういった問題を解決するために、J2EEを使ったシステム開発では「J2EE」や「オープンソースのフレームワーク」をベースに、それぞれの開発プロジェクトで必要なインフラストラクチャを構築して開発を効率化するといったことが、しばしば行われます。開発プロジェクト固有のインフラストラクチャがあればアーキテクチャの管理が一元化でき、アプリケーションの強化や改修をより柔軟に行うことができます。

　Springフレームワークが対象とする領域は、このようなプロジェクト固有の「インフラストラクチャ」を構築することだといえます。

　Springフレームワークは、柔軟なインフラストラクチャを構築できることを目指して作られています。以下の章ではSpringフレームワークが、柔軟なインフラストラクチャのためにどういった機能を提供しているかということを説明していきます。

「ポイント」
Springフレームワークが対象とする領域は、プロジェクト固有の「インフラストラクチャ」を構築することです。

アスペクト指向プログラミング（AOP）は機能を挿入する仕組み？

　もしも読者がAOPの初心者でAOPの概念についてまだ理解できていないならば、（最初のうちは）以下のように「割り切って」理解してしまうことをおススメします。

「ポイント」
AOPとは作り上げたオブジェクト群に対して「機能を挿入する（織り込む）」ことができるアーキテクチャである。

　つまり、作成したオブジェクト群に対して「アトヅケ」で機能や処理を挿入することができる仕組みだと考えてください。

　一般的には、AOPは「横断的関心事の分離（Separation Of Cross-Cutting Concerns）」を行うものだといわれています。この「関心事」とは大ざっぱにいうと「ひとまとまりの処理」であり、また「横断的」とは「複数のモジュールに散在する状態」を指します。つまり「横断的関心事の分離」という言葉は、本来1カ所で定義されるべき「ひとまとまりの処理」が複数のモジュールにまたがって存在している状態であるため、それらの処理を抜き出して別途定義するべきであることを表しています。

　しかし、実際にこれからAOPを使ってプログラミングをしようとする開発者にとっては、この抽象的な言葉から「どう使って」「どのようなメリットを生み出すことができるのか」をイメージすることは難しいでしょう。

　「横断的関心事の分離」という言葉が理解しづらい理由は、「プログラミングという視点」と「分析という視点」の違いにあるのではないでしょうか。「横断的関心事の分離」という言葉は、「分析的」な視点で語られた言葉です。「分析」という行為では、すでに存在するものを「発見、定義し、分類する」という作業を行います。それに対して、「プログラミング」という行為は「存在しないものを作り上げる」作業を行います。AOPを初めて扱う人がいきなり分析的な観点でAOPに取り組むことはまれであり、たいていはプログラミングのフレームワークとしてAOPを扱います。そのためAOPの「横断的関心事の分離」という言葉を理解しづらく感じてしまうのです。

　しかし、「アスペクト指向」という概念は、プログラミングのみならず、アスペクト指向「分析」やアスペクト指向「設計」なども含んだ幅広い概念です。そのため、「横断的関心事の分離」といった抽象的な言葉を使わなくては、アスペクト指向の幅広い概念を（正確に）いい表せないのです。