「データ」と「処理」

先週の土曜日に“「サービス」と「処理」”という記事を書いた。内容的に飛躍しているところがって、今ひとつまとまりのない記事になってしまった。
ただ、似たようなことは相変わらず考えているのである。
今回は、“「データ」と「処理」”にタイトルを変え、まとまった記事になるように心がけて、検討を続けていく。

オブジェクト指向設計において、サービスや処理、つまり責務側面は、どのように設計するのか。
責務側面といえば、最初に出てくるのはユースケースである。ユースケースは、どのようなレベルで書くのかで意味合いが変わってくる。一般的にはSuD（System Under Discussion…議論対象のシステム）のレベルで書くだろう。それは、「アクターが、そのシステムに何をして欲しいか」である。つまり、それがシステムが実現しなければならない機能となる。

ユースケースは、システムが実現すべき責務であっても、1つ1つのクラスが実現すべき責務ではない。粒度が違うのである。クラスとして実装するためには、責務の粒度をユースケースより小さくしていく必要がある。
その方法の1つに、ロバストネス図を書く方法がある。
ロバストネス図は、画面等（バウンダリ）を起点として、処理（コントロール）とデータ（エンティティ）との関連を検討する図である。基本的には、ユースケースシナリオに沿って、書いていく。
（この辺の話は、「ユースケース入門」が詳しい。ロバストネス図はUMLには含まれていないのだが、例えばJudeならクラス図の一種として書ける。ロバストネス図は、ダイコン時代の設計手法である「くーす」でも活用されているようだ。）

ここで登場したコントロールが、前回から検討している「サービス」の粒度である。3層レイヤリングでの1つのサービスに相当する。（だから、トランザクション単位でもある。）
5月の記事から始まっている（長い休みを挟んだ）この検討は、要はデータと処理をどうするか？という内容である。
5月の時点では、オブジェクト指向ではデータと処理はまとめるはずなのに、分けることが実装時点で推奨されることに違和感を感じていた。
11月12日の記事では、データと処理を盲目的にまとめることは違うのではないか？というところまでたどり着いた。
ここからが、今日の本題である。（長い前振りだった…）

今、私の前には、良く設計されたドメインモデル（アクセサ程度のメソッドしかないから、データモデルのようなものである）と、ロバストネス図で抽出したコントロールがあるとする。
私は、コントロールを、どうやってドメインモデルにマッピングしていくと良いのだろうか。つまり、処理をデータにどうやってマッピングするのか。

名著と誉れ高い「実践UML」によると、GRASPというパターン集が提示されている。GRASPは汎用的な責務の割り当て規則といえるもので、今回の問題に真正面から答えてくれるものといえる。
GRASPには、いくつかのパターンがあるが、責務（ここでいうコントロール）の割り当て先として、以下の3つが挙げられている。

• 情報エキスパート（責務の遂行に必要なデータを持っているクラスに責務を割り当てる）
• 生成者（あるクラスAの生成に必要なデータを持っているクラスBに、クラスAのインスタンスを生成させる）
• コントローラ（ユーザ操作に起因する責務を、ドメインモデルには登場しない純粋架空物クラスを作って割り当てる）

この他にも、高凝集性や疎結合性、バリエーション防護といったパターンが存在するが、乱暴に言えば、それらのパターンは、上記3つのパターンを選択するにあたっての評価基準だったり、補足のアイディアだ。

ここで、生成者パターンは横に置いておこう。なぜなら、インスタンス生成の責務しか割り当てられないからである。
これで情報エキスパートとコントローラ（コントロールではない。コントロールする主体だからコントローラだ！）の2つにフォーカスが当たった。

情報エキスパートは、データと処理をまとめる発想であり、正にオブジェクト指向的と言える。
一方、コントローラは、データと処理が分離されることになる。故に、コントローラは薄く作るべきと言われているし、機能分割手法に慣れ親しんだエンジニアには特に強く注意を与えている。コントローラは、やるべき仕事を出来る限り別のオブジェクトに委譲し、アクティビティの調整と制御に没頭すべきとされている。（3層レイヤリングのサービス層の責務として、同じような話を聞いたことがありますね…。）

ついに問題の核心にやって来た。
私の言いたいこと（これまで考えてきた結論）は、こうである。

「往々にして狂信的オブジェクト指向者は、責務を過度に情報エキスパートに割り当てようとする傾向が強い。その結果として凝集度の低い、別のドメインオブジェクトとの結合度の高い設計をしてしまう。場合によっては、情報エキスパートに割り当てられた責務が1つのトランザクションそのものとなってしまい、それを永続化する際に過度に複雑なロジックが必要になることすらある。」

求めるべきは、高凝集性と疎結合性である。元々、この2つを求めてオブジェクト指向に取り組んだのに、度が超えて、逆に低凝集性と密結合性を追及するハメになる。良かれと思ったのに…残念ながら、やり過ぎてしまうのである。

では、どうすべきか。

「情報エキスパートとコントローラはバランス良く使わなければならない。本当に高凝集性と疎結合性を実現するのなら、情報エキスパートによって割り当てられる責務（コントロール）は、自分自身が持つデータ（属性）か、関連するオブジェクト（ひょっとすると、コンポジションの子ぐらいまで絞っても良いかもしれない。）が持つデータだけで実現できる責務に限られる。良く設計されたドメインモデルはクラス間の関連は適度（ちょっと関係しているからと、安易に関連を引くべきではない。もし、同じ要件を満たすために関連を引く方法と、無理なく引かずにすむ方法があるなら、引かない方法を選択すべきである）であるから、情報エキスパートが採用できるのは、期待したより少ないかもしれない。それ以外は、コントローラにやらせるべきである。ただし、間違ってもコントローラが情報エキスパートの仕事を奪ってはいけない。」

長くなったが、こういうことではないかと、今は思っている。
だから、5月に感じた疑問は、このような考え方で望めば、特に疑問ではないのであるし、データと処理を盲目的にまとめることには自制が必要だ。
オブジェクト指向のデータと処理をまとめるアイディアは、あくまで高凝集性と疎結合性を実現するためのものであることを、忘れてはいけないのである。

最後に、サービスと処理について。
どちらの言葉も明確な定義のない言葉ではあるが、元々、この2つの言葉を取り上げて比較してみたのは、オブジェクト指向と従来手法の比較がしたかったからである。
つまり、最近、オブジェクト指向設計とともに取り上げられる3層レイヤリングのサービス層なるものは、従来手法の処理と何が違うのかということだ。
もっと言うと、「（サービス層にある）サービス」でやることが、もしビジネスロジックそのものであるなら、従来手法での「処理」と同じではないのか？ということになる。

その答えは、以下のようなものである。

従来手法での処理はモジュール分割され、制御モジュールと実際の処理を行うモジュールになる。その点では、サービス＝コントローラとドメイン＝情報エキスパートが分担してビジネスロジックを片付ける様に似ている。しかし、従来手法とオブジェクト指向では分割（分担）の軸となる考え方が異なっている。従来手法は、やはり処理を考えて分割するのであるし、オブジェクト指向はデータを考えて分担していく。
さらに言葉に注目すると、従来手法は「分割＝分けること」であって、オブジェクト指向は「分担＝分けたものを誰かにやらせる」のである。その「誰か」が、データ＝オブジェクトなのだ。
だから、見た目は遠目から見る分には似通っているが、近くまで寄って、実際にどのような分割（分担）がなされたかを見ると、それは違うものなのである。

まぁ、これといって目新しい結論でないのは恐縮だが…。

最後の最後にもう1つだけ。
上記で「狂信的オブジェクト指向者」を挙げたが、実は入門書どおりの設計をやりたがるオブジェクト指向初心者も同じ罠にハマりがちではないかと思う。
これは完全に私見ではあるが、入門書はあまりにも綺麗にオブジェクト指向出来ているケースが多く、初心者は、それが唯一の正解だと思い込んでしまうのではないだろうか。