オブジェクト指向の本では「自転車をモデリングしてみましょう」「鳥をモデリングしてみましょう」ということが、どういうシステムで使うか規定せずによく書かれています。
けれども、モデリングではどういうシステムで使うかということが大事で、それを決めずにモデリングを考えても意味がありません。モデリングすべきはモノではなくシステムのプロセスです。
よく、オブジェクト指向では現実をモデリングするのようなことが言われますね。
例えば鳥が鳴くとして、その一種であるニワトリをどうモデリングするか、ということを考えるとします。
そうすると、まず
void 鳴く() {
print("コケコッコー");
}
のようなメソッドを考えるのですけど、コケコッコーとうまく鳴けるのは鳴き慣れたニワトリです。そのため、鳴くメソッドにカウンターを用意してどんどんうまくコケコッコーになるようにしたくなります。
いや、そもそも、コケコッコーと鳴くようになる前、ヒヨコとしてピヨピヨ鳴いています。ヒヨコからニワトリへの遷移も必要になるのでは？
また、インフルエンザなどの病気にかかればうまく鳴けなくもなりそうですね。
「現実をモデリング」をやろうとすると、どんどんコーナーケースがでてきて、そのすべてのコーナーケースに対応しようとすると、結局は細胞モデルや分子モデルなど、微細要素まで分解してシミュレーションすることになっていきます。
そもそもモデリングというのは抽象化なので、現実のシミュレーションではないですね。
そして抽象化というのは、必要な要素を残して不要な細部を切り捨てる作業です。では何を残して何を切り捨てるかというのは、何に使うかということなしには決めれません。
モデリングでは「何に使うか」が重要です。
何に使うかということなしでは上記のニワトリモデリングのように、いろいろな条件をどんどん再現する必要がでてきます。そして、この作業は結構たのしいので、目的なくどんどんモデルを膨らませていくことになります。
目的が決まっていないモデリングは、モデリングのためのモデリングになってしまいます。
実際には、どのようなシステムで使うかということが、何をモデリングするかよりも大切です。
たとえばデータをメモリだけで扱うのか、ファイルに保存するのか、データベースに保存するか、データベースはMySQLかMongoDBか、そこでモデルの大きな方向性が決まります。
なにを目的にするのかも大切です。販売管理なのかゲームなのか動物百科事典なのか。
販売管理で、肉屋だとニワトリを仕入れてさばいて部位ごとにわけて、一部はミンチにして、という扱いが必要です。システム化のことを考えずにそういった解体可能なニワトリモデルを考えると、骨や肉、羽、そして細胞のモデルまでいきついてしまいますが、ほとんどは販売管理に不要な詳細になります。
現実をモデリングするのであれば、モモやムネの肉オブジェクトは仕入れたニワトリオブジェクトの一部である必要がありますが、実際には仕入れたニワトリと解体されたモモ肉は無関係なオブジェクトで構いません。
そして、このときのモデルを決めるのは、「ニワトリとはどういうものか」ではなく、「ニワトリの肉を売るとはどういうビジネスか」です。ニワトリとモモ肉は無関係でいいと書きましたが、トレーサビリティでモモ肉の生産業者わかるようにするとしても、大事なのはニワトリのモデリングよりも農水省のトレーサビリティ関連文書でしょう。
結局のところ、モデリングするべきは、モノではなくプロセスです。プロセスをモデリングしたあとで、そのプロセスを可能にするデータとしてモノをどうあらわすかというモデルが必要になるわけです。
オブジェクト指向が衰退した流れのひとつに1990年代後半に開発手法から開発プロセスに関心が移ったことを取り上げるのですけど、90年代後半にビジネスプロセス・リエンジニアリング(BPR)という言葉が流行りビジネスプロセスを分析設計することに関心が集まったこともオブジェクト指向の衰退に無関係ではないのかもしれません。
追記 2024/4/14
こういうモデリングはいつからあるんだろうというコメントありますが、オブジェクト指向モデリングの原典とも言える「オブジェクト指向方法論OMT」の最初に自転車の例があります。ただ、これはコンセプトを示すためで、実際の例としてはATMなどもっと実務に即した題材を使っています。意図せず広まってしまった感じ。
ランボーのOMT本はオブジェクトモデル→状態遷移→データフローと章が進んでいるけど、現実的には逆のほうが適切ですね。そこでヤコブソンのOOSEと組み合わさって、ユースケースを起点としたICONIXやRUPにつながっていきました。
