今、オブジェクト指向とよばれているものは、結局のところクラス指向です。
オブジェクトを見出して、そこからクラスを見出して、クラス同士の関連を見出すという流れになります。
その結果として、たとえば僕が今この文章を書いているパソコンと、あなたが今この文章を読んでいるパソコンは、同じパソコンクラスに属するものとして、非常に近い関係になります。*1
この関係は、僕のパソコンで電源ボタンを押したときとあなたのパソコンで電源ボタンを押したときにだいたい同じ動きをすることをあらわすのには効果的です。
パソコンクラスを書いて、電源ボタンメソッドを書いて、僕のパソコンとあなたのパソコンがパソコンクラスのインスタンスであることを示せばいい。
ところが、僕のパソコンの上に置いてある空き缶は、クラス設計上まったく関係がありません。
パソコンクラスの属性に空き缶コレクションを持たせようとすると、きっとキレイ好きでパソコンの上に空き缶が乗っているのを許せないあなたは強く反対するはずです。
代わりにパソコンクラスの属性としてボトルキャップフィギュアコレクションを持たせたいと主張するかもしれません。おしゃれなあなたは観葉植物コレクションの属性が必要であるというかもしれません。
そんなことされたら、ぼくの本の置き場がなくなってしまう。まっぴらごめん。
この「ただ隣り合っている」関係を、クラス図を先に書くようなオブジェクト指向で記述するのは非常に難しく、まず「場」となるクラスを持ち込む必要があります。
慎重に「場」のクラスを設計したら、そこに「パソコン」や「空き缶」「ボトルキャップフィギュア」「観葉植物」を放り込めるようにして、それらの位置関係を記述できるようにします。
そうしてできたクラス図を見てみると、ぼくのパソコンの上の空き缶群も、あなたのパソコンの上のおしゃれな観葉植物も、まったく想像できない無機質な図ができあがりです。
パソコンの上の空き缶を表現するためには、また一作業。
そうすると、どこかで情報がかけて、ぼくの机がちらかっているという情報がどこにも記述されなくなったりするわけです。あなたがぼくの机の上を見ることになって、でもぼくは机の上がちらかっていることを忘れてしまっているので、見事にちらかった机が目撃されてしまうことになります。
ぼくは机の上のちらかり具合を常に把握して、必要に応じて片付けなくてはならない。ましてや写真とられて本に載るとなったら、一日かけて大掃除ですよ。
要するに、今の「オブジェクト指向」はオブジェクトに対して無頓着で、オブジェクトの関係を表すのが非常に苦手だということです。
クラスを記述することでオブジェクトも記述できているつもりになっているようにも思えます。
で、実際にはオブジェクトの関係を表現するための場を記述することで力尽きてしまいます。
UMLの表記でStrutsの画面遷移がInputActionからResultActionに移るということを示すのに、どんな作業が必要でしょうか？
クラス中心のオブジェクト指向では、作業の途中でオブジェクト同士の関係が消えてしまいやすいというのが、大きな問題点じゃないかと思います。
*1:この2つの「今」の違いが大好き
