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

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

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

!!物と結果がクラス
それではクラスにすべきものは何でしょうか?\\
システム要件の中に出てくる「物」と「結果」の2種類です。\\

!!物クラス
この種類に分類されるクラスは、実際に存在する物として人間が認識出来るものです。\\
データベースのマスタデータとして分類されるものです。
*商品
*組織
*顧客
*発注先会社
*通貨

!!結果クラス
この種類に分類されるクラスは、人間やシステムが行った結果を記録したものです。商用のシステムの場合は「取引」の結果が中心となります。紙の伝票として書いてあったものは全てこの種類のクラスです。その他に、システムが行った通信の結果を記録したもの(ログ)などもこれに分類されます。\\
データベースのトランザクションデータとして分類されるものです。
*受注伝票
*発注伝票
*経理仕訳
*アクセスログ
*金額
*日付
*画面上の座標

!!受注伝票で考えてみる
商品を受注した時の伝票を考えてみます。(受注時のオブジェクト図)\\
[order_objects.png]\\
\\
上記図中のオブジェクトをまとめると次のクラス図が考えられます。\\
[order_classes.png]\\
このクラス図中の金額クラスは商品単価の金額値を持つクラスです。商品単価は「ある特定の日の商品の売り値(金額)」として定義されます。\\
日付クラスは、受注伝票クラスでも商品単価クラスでも利用されます。\\
ところがこのクラス図には問題となる部分があります。商品が受注個数を持つようになっていますが、受注個数は受注のたびに変わるため、商品の一部としてこれを持つのは無理です。正しくは、「商品/受注個数/商品単価」の組合せとする結果クラスとして持つべきです。受注明細と一般的に言われるものです。\\
これを訂正したのが次のクラス図です。\\
[order_classes2.png]\\
!!金額クラス
商品単価クラスが持っている金額クラスを考えてみます。日本の通貨である円を前提にするならばクラスにするまでもなく、intなどの整数属性として持てばいいように思えます。\\
しかし金額クラスとして定義しておけば次のような振る舞いを持たせることが可能になります。\\
*消費税金額を返す
*カンマ及び通貨記号で編集した文字列を返す
日本において消費税計算は特に重要で、計算の基となる情報として「消費税区分(内税/外税/税額)」が必要になります。「税額」という区分値は、その金額が消費税自体を表す時に使います。これらを反映したのが次のクラス図です。\\
[amount_class.png]