ソフトウェア開発において、基盤層や基本部品（画面部品、ウィンドウシステム、標準ライブラリ、API）や、中位層（フレームワーク、ミドルウェア）の再利用・実現に関しては、オブジェクト指向は絶大な威力を発揮し、実績としては大成功を収めたといっていいでしょう。このレイヤにおけるオブジェクト指向というコンセプトは、今後とも不動不滅のものではないでしょうか。
しかし、その限界が露呈するのは、ビジネスロジック層、アプリケーション層に関してです。その理由はこのレイヤが、案件ごとの依存性が高く、いちばんやわらかく、開発の間を通じてすら可変であり、要はいかにも「再利用が難しい」からです。このレイヤでは、とりあえずクラス・クラス群と言う単位が再利用単位としてはそうそううまくは機能しないことがわかってきています。
しかし、前にも書いたとおり、Grailsとその上での「プラグイン」という単位は、そのようなシチュエーションでの再利用に対して立ち向かいうる一つの可能性を提示していると考えています。その理由は以下のとおりです。
- プラグインは、ロジックだけではなく、taglib、テストコード、コントローラを含んでおり、粒度が大きい。なお、テストコードは仕様書として振る舞い、taglib はユーザーインターフェース（入出力）を表している。要は、プラグインは、ロジックだけではなく、入力、出力、コンテキスト、テストを含めた「フルスタックの再利用部品」であるということです。
- Grailsは、アスペクト指向・ドメイン指向を取り入れたフレームワークであるということ。Grailsのユーザコードの中心「ドメインクラス」は、メソッドとしてのロジックをあまり持たない、つまり他への働きかけが少ない＝他に対する依存性が極めて薄い。各種の情報は「宣言的に」含んでいるデータ的存在、いわば「消極的なオブジェクト」であり、受身のピボットとして動作します。このような状況であるからこそ、個々のプラグイン同士が干渉しにくく、独立して機能を発揮しやすいといえます。個々のプラグインは「織り重なるように」、非侵襲的に協調動作するのです。
以上は、調べたり何人かの方から聞いた話を自分なりにまとめた、印象論的かつ（自分にとっては）状況証拠的な話ですが、これから経験を積んで実感をつかめるか試していきたいと思っています。
参考:
