「プロセス志向」と「オブジェクト志向」の比較を続けます。
要望を分析する段階で、プロセス志向ではいきなり実装に近いことを考えることが出来ました。それに対してオブジェクト志向では、オブジェクトを抽出するところから始まりました。つまり、設計にはいるまでに時間がかかりそうです。
ところで、アプリケーション プログラムのライフサイクルを思い浮かべてください。まず、「計画」を行います。そして、「設計」を行います。設計に基づいて「実装」を行います。実装ができると、「テスト」を行います。設計、実装、テストは、小さく繰り返すことがあります。そしてリリースされ、「メンテナンス」に入ります。メンテナンスをしながら気がついて点などを次のリリースのために「計画」に組み入れます。・・・。
このように、「計画」→「設計」→「実装」→「テスト」→「メンテナンス」を繰り返すわけですが、一番最初の「計画」「設計」以外は、「最初のリリースのメンテナンスである」と、言えないでしょうか。そう言っても良いなら、アプリケーション プログラムは、設計や実装の期間と比べると、比較にならないほど長いメンテナンス期間を持っていると言えるでしょう。
私が「オブジェクト志向プログラミングっていいなぁ」と思うのは、この「メンテナンス」期間においてです。
前回、プロセス志向のところで「「ファイルの移動をどうやって実現するか」ということが、よくわかると思います。」と書きました。しかし、オブジェクト志向については、該当するものを書いていません。では、オブジェクト志向設計では、何がわかりやすいのでしょうか。
前回のお題は、こうでした。
「ローカル ディスク上の任意の場所にあるファイルを、ローカル ディスク上の任意の場所に移動する。」
そして、オブジェクト志向プログラミングに対する設計は、こうです。
「ファイルの属性「場所」を、新しい場所に設定する。」
どうでしょう？お題がほぼそのまま設計になっています。いくつかの制約、前提条件がありますが、それらが整っていれば、要望から仕様を作ること、仕様から実装を行うことが、とても容易に行えます。その制約、前提条件とはなんでしょう。オブジェクトが、オブジェクトとしてできあがっていることです。このため、最初の設計では苦労すると思います。しかし、長いメンテナンス期間において、仕様書の何を変更すれば実装のどこを変更しなければならないか、明確になっているのではないでしょうか。
ということで、次回は実際に変更を行ってみようと思います。
投稿日時 : 2008年12月28日 21:14