オブジェクト指向っぽいなにか

オブジェクト指向の究極は、オブジェクト指向であることがみえなくなるのだと思う。 フレームワークって言うのがまさにそうで、フレームワーク自身が設計の多くをまかなう故に、オブジェクト指向設計をさせない作りになる。テンプレートメソッドのメソッドを埋めればアプリとして動作する。例えばGrailsを使う場合、アプリをくむ立場からはオブジェクト指向の要素はほとんどありません。でも使ってない訳じゃなくて、間接的に使っていて、使っていることが見えないほど巧妙になっているだけ*1。 クラスライブラリというのもそういうものです。継承を多用させるなど、オブジェクト指向を熟知することを利用者に強要するようなクラスライブラリは、API設計としてはよろしくない。 しかし、それは、オブジェクト指向の失敗ではなく成功です。

まさにその通り。私が上手く説明できなかったことを文書に落としてある。素晴らしい。
フレームワークが洗練されているからこそ開発者はオブジェクト指向を意識しなくてもいい。
開発者がオブジェクト指向を意識しないと使えないような設計は使いにくい(作りにくい)よね。
 
ちょっと話は変わるけど、
Webアプリを作る時に、最近は画面クラスとビジネスロジッククラスを一対一で作ります。過去に「それって正しいオブジェクト指向設計なのか?」と指摘されたことがありました。その時にうまく相手を納得させることができなかったような気がします。その答えは行き着くところここだったんだと思いました。


以前は、ビジネスロジッククラスを画面と関係無く概念として抽出して作っていた時がありました。そうするとオブジェクト指向ぽいです。設計としては綺麗に見えました。実際きれいで気持ちのいいものでした。(少なくとも私には、、。)ただ、これには問題がありました。概念を理解できない人には難しいのです。メソッドを作成する際にどのクラスに追加すればいいのか?はたまたクラス自体を作成すべきなのか?人によっては悩みが出ました。そういう悩みを無くすために次のようなルール付けをすることで分かりやすくしました。

  1. XxxをYyyするという処理を羅列する。
  2. Xxxをクラスにする。
  3. YyyをXxxクラスのメソッドにする。

しかし、これでもまだまだ難しいと感じる人がいます。それにこれは実際に作っていくと指針としてはどうしても曖昧です。
そこでふりかえりました。本当に画面とビジネスロジッククラスは1対nがいいのか?その結果として私の今の結論は一対一です。共通的な処理が出てきた時点で概念として抽出していたようなクラスを作ります。一対一の場合は、開発者が悩むことなくコーディングができます。そもそも、ビジネスロジッククラスってなんやねん!という考えの元に画面クラスに実装するのも小さい画面ならあり得ます。


なんか話ずれまくったけど、なんか思いついたので。