ページ本文 ファイル添付 (6) ページ情報
This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

役割ではなく、それを実行するための状態を考える#

クラスを定義する際にはユーザからの業務要件が基になりますが、それはシステムあるいはプログラム、つまりオブジェクト指向で言えばクラスの役割を規定しているだけです。役割を規定しただけではモノを決められないことは前述の通りです。
私たち開発者は、その役割を実現出来るモノはどういう状態であるべきかを考える必要があります。状態はデータ構造によって規定されます。
繰り返しますが、その内部の状態がどうなっているかはクラスを利用する側からはあまり重要ではありません。利用する側からは「何をしてくれるのか」が重要だからです。
しかし開発者は、「それをするためにはどうあるべきか?」を考える必要があります。

クラスにしてはいけないもの#

実際の設計をする上でクラスを考える際、「何をクラスにすべきか」よりも「何をクラスにしてはいけないのか」を考える方が近道です。クラスにしてはいけないのは次のようなものです。
  • ファイル送信クラス
  • データ受信クラス
  • ログ制御クラス
  • メッセージ表示クラス
  • 従業員管理クラス
  • :
  • :
全てに共通するのが、動詞となる名前が付けられていることです。「送信する」「転送する」「出力する」「表示する」「管理する」です。
動詞になる名前を持つということはすなわち処理に着目して定義されています。つまりそれは処理を共通化しようとしてクラス化されています。オブジェクト指向において共通化すべきなのは処理ではなくデータ構造なのです。
上記の延長線上として、英語の動詞に'er'や'or'を付けた名前のクラスも誤りです。
  • Controller
  • Sender
  • Receiver
  • :
  • :
これらは動詞を無理矢理名詞にしただけで本質は上記と変わりません。そしてこれらは「役割」を表現することがほとんどで、Interfaceとして定義されるべきものを多く含んでいます。

クラスには境界がある#

クラスを設計する際に必要なのはデータ構造を考えることです。データ構造というのは「ひとかたまりとして扱いたい情報」です。
AクラスとBクラスを異なるクラスとして定義するということは、Aの情報のかたまりとBの情報のかたまりとの間に境界があるということです。境界がなければ同じクラスでも構わないからです。境界線を引いた上で、境界線の内側にある情報(属性)が同じクラスとして扱われるべきです。
boader.png
処理に着目してクラスを定義すると、上記のような境界線は見つかりません。2つの処理がある場合、それを1つのクラスに実装しても2つに分けたとしてもいずれでも実装出来てきてしまいます。2つの処理に明確な境界線は引けないからです。
しかしデータ構造の場合は人が認識出来る境界線が上記の図のように必ずあります。

クラスとなるもの#

それではクラスにすべきものは何でしょうか?

添付ファイルの追加

ログイン済のユーザのみが添付ファイルをアップロード出来ます。

添付ファイル一覧

Kind Attachment Name Size Version Date Modified Author Change note
png
 amount_class.png 3.4 kB 3 24-2-2011 00:45 ytp
png
 boader.png 9.7 kB 1 03-2-2011 01:37 ytp
png
 order_classes.png 6.6 kB 5 31-12-2011 19:19 ytp
png
 order_classes2.png 6.9 kB 4 31-12-2011 19:20 ytp
png
 order_classes4.png 9.9 kB 2 31-12-2011 19:39 ytp
png
 order_objects.png 11.7 kB 1 21-2-2011 23:06 ytp
« This particular version was published on 03-2-2011 01:33 by ytp.