｢ビジネスロジックを設計する上で、オブジェクト指向ってどのように使いこなせばいいのだろう。｣
そう思ったことはないでしょうか。
｢システムが扱うオブジェクトをもとにアーキテクチャを構築する｣っていっても
現実の世界からソフトウェアの世界へオブジェクトを間違いなく抽出するのは難しいものです。
Javaのようなオブジェクト指向言語を使っていれば、確かにオブジェクト指向言語のメリットは
理解できます。しかし、それを設計に生かそうとすると、とたんに難しく感じられないでしょうか。
顧客の要求は、｢何をどうする｣というように機能中心であり、
オブジェクトなどは意識していません。
オブジェクト指向だと、顧客の要求を分析する際に、
顧客の思考パターンとギャップがありすぎるため、難しく感じるわけです。
一言でオブジェクト指向といっても、オブジェクト指向分析、オブジェクト指向設計、
オブジェクト指向プログラミングの3つの部分に分けられます。
オブジェクト指向分析は、顧客の思考パターンとギャップがあるため、
要求分析には向いていません。
デザインパターンに代表されるようなオブジェクト指向設計は、
一見有効に見えます。しかし、開発はチームで行っていることを考えると
チームのほとんどのメンバが理解できて、メンテナンスできる場合にだけ、
用いたほうが良いように思われます。
オブジェクト指向プログラミングは、積極的に活用すべきでしょう。
それでは、どのようにして要求分析を行えばよいのでしょうか。
構造化手法を思い出してください。
機能をブレークダウンしながら分析していく手法は、要求分析にはぴったりです。
手続き型による設計も、誰でも理解しやすく好ましいものです。
ただし、問題は構造化プログラミングにあります。
かつての構造化プログラミングは、手続き間の結びつきが強いという問題点がありました。
どういうことかというと、A、Bという手続きがあった場合に、
Aを呼び出した状態にBが依存しているため、Bだけを再利用できない、
あるいは、Aを修正すると、依存関係のあるBも修正が必要になるといった問題です。
要求分析に向かないというオブジェクト指向の弱点と、
手続き間の結びつきが強いという構造化手法の弱点を解決するために、
生まれたのが、ルール指向アプローチです。
ルール指向アプローチでは、データ(状態)と手続き(ルール)を分離します。
人間の思考パターンには、データと手続きを分けて考えるほうが向いているのです。
ルール指向アプローチでは、顧客の要求を構造化手法を使ってルールにブレークダウンします。
また、個々のルールをステートレスにすることで、結合度も低くすることができます。
そして、ルール指向アプローチを具体的に実現するフレームワークがNazunaになります。
ルール指向アプローチを成功させるためには、次の3原則を守ることが重要です。
Nazunaは、seasar-context.xml
を書き換えれば、Seasar以外のアプリケーションサーバでも稼動します。
J2EEに準拠したアプリケーションサーバ間でポータルなわけです。