オブジェクト指向の光と影

ソフトウェアの構成物をオブジェクトという単位で捉えるオブジェクト指向は、ブームからコモディティへとこなれてきたと思う。しかし、そこには指摘する人が少ない影の部分が存在していると感じたので、それを記しておく。

１）開発プロセスの変遷からの類推

　ウォーターフォールからアジャイルへの変化や分化などは最適化の結果と捉えている。
　地図を例にとると、平面の四角い紙に表す地図(メルカトル図法)は、一定の狭い範囲での表現としては最適であるが、地球全体にまで領域を広げると形が歪んでしまう欠点がある。逆に地球儀のアイデアを狭い範囲で忠実に実現しようとしても精度的に無意味になってしまう。
　つまり、対象とする事物や扱う方式によって最適なものは変化するということだ。
　ユニファイドプロセスなどは、ウォーターフォールのやり方を部分最適な方式として捉えており、ソフトウェア開発をモジュール化してその一部を実行する時のプロセスとして採用し、これをイテラティブ・インクリメンタルに行うこととした。
　一方アジャイル開発では、ウォーターフォール的な手法を採用する場面はもっと限定的になる。

　開発方法論は、統一(Unified)のかけ声よりも、現実に即した進展をしたと思う。それは、１つの手法ですべてを統一するのではく、状況に合わせて最適なものを採用するという方式だ。

２）分析・設計手法におけるオブジェクト指向

　ソフトウェアの世界をデータと振舞を内包した要素とその関連として捉えるオブジェクト指向は、ある領域では最適だと言えるが、無制限に一般のソフトウェアを対象に出来る訳ではない。
　オブジェクトは仮想的なモジュールとして捉え、それがデータを内包し、他のオブジェクトと関連を持つと捉えるのがOOの基本であるが、この考えはある程度の固まりとしてのソフトウェアコンポーネントやサブシステムという単位ならとてもしっくりするのであるが、細かくなってくると現実と整合しずらい部分が出てくる。
　たとえば、機能や振舞を細分化し抽象化していくと、特定のオブジェクトやそのクラスに属する限定をしないほうが扱いやすい、純粋に抽象的な機能というものも見つかり、無理やりにオブジェクトと捉えると何のデータも持たない要素となってくる。また、データの方も同様にまったく何の機能を持たせる必要性がない固まりというのも存在する。さらに、振舞に関する関連とデータに関する関連では、構造を定義しているという点では同じだが、意味合いは全く異なっており、データ同士の関連は状態を意味する一種のデータとして使われるが、振舞同士の関連が状態を意味することは通常ない。
　通常と言ったのは、振舞同士の関連に状態を持たせようと思えば出来るからであり、この「やろうと思えばできる」的な曖昧さが、OOでの分析・設計をぶれの大きなものにしてしまっているように感じる。
　異なっているのに、共通的に取扱えるから同じ用語やコンセプトで押し通されてしまうと、本当に重要な”違い”が見過ごされてしまうような気がする。

ではどうするかは、これからの検討課題とする。