!!単位が異なれば同じ物でも異なるクラスになる
「__一個売りしているリンゴ__」をシステムで扱う場合、どのような属性が必要になるかを考えてみます。\\
#品種
#重さ
#売り値
#入荷日 [{Image src='apple_1ko.gif'}]
などが考えられます。それでは、「__一山(ひとやま)売りしているリンゴ__」はどうでしょうか?
#品種 (同じ山には同じ品種を乗せる前提)
#重さ (一山あたりの総重量)
#売り値 (一山あたりの総額)
#個数 [{Image src='apple_1yama.gif'}]
上記を較べてみると、同じリンゴでも違いのある事が解ります。処理を考えてみるとさらに明らかになります。\\
「一山売りしているリンゴ」では、「__一個あたりの売り値(平均の売り値)を返す__」というメソッドがすぐに思い浮かびます。\\
これらから解るように、「リンゴ」というクラスが設計段階、特に概念モデルで出てきても、それが一個なのか一山なのかを確定させないと正しいクラスとして設計できません。裏を返すと、同じリンゴであっても、それを扱う__単位が異なれば異なるクラス__として設計する必要があるということです。\\

!!要件の中に出てくる単位を見逃さない
前項で解るように、__単位は非常に重要__です。ここで言う単位は物理学で言うものではなく、__業務を遂行する人たちがあるものをひとかたまりとして扱う大きさ__のことです。
*一伝票
*一明細
*一会社
*一組織
*一箱
*一取引
*一件
*一覧
など色々ありますが、人間が何かをひとかたまりとして扱い、そのかたまりの種類が異なる場合には必ず単位が異なります。もちろん、非常に汎用的な「一個」という単位はあちこちに出てきますが、その場合は「何々一個」というように聞き分けて設計していけば問題ありません。\\

!!実際のシステムでは一件クラスと一覧クラス
このページの見出しにあるリンゴ一個とリンゴ一山」は、実際のシステムではどう考えればいいのでしょう? 答えは簡単で、__「『一件』と『一覧』は異なるクラスとして設計・実装する__」です。『一件』がリンゴ一個に相当し、『一覧』がリンゴ一山に相当します。\\
例えば業務要件を聞いている中で「顧客会社クラス」が出てきた場合は、
#「顧客会社一件クラス」
#「顧客会社一覧クラス」
の二つの可能性があります。
顧客会社を一件のみ、つまり一会社として扱う時のクラスが「顧客会社一件クラス」です。__複数件で__、つまり顧客会社を一覧として扱う場合は「顧客会社一覧クラス」を作ります。一覧クラスは一件クラスを__内部で複数持つ__ように設計します。ほとんどのシステムにおいて両方必要です。\\
[{Image src='single_multiple.png'}]
別の例を出しましょう。入荷予定の結果クラスである「入荷伝票」を考えてみます。\\
[{Image src='nyuuka1.png'}]

入荷業務で良く出てくる、\\
*入荷伝票
*入荷明細
は、「一伝票」と「一明細」というように単位が異なるので別クラスとして定義します。伝票は、ある仕入れ先からのある日の入荷物全体を表現しています。__伝票ヘッダ__とも言われます。明細は商品単位の情報を持っており、一伝票が複数の明細を持つ形です。
[{Image src='nyuuka2.png'}]

さらに、\\
#入荷伝票一件クラス
#入荷伝票一覧クラス
#入荷明細一件クラス
#入荷明細一覧クラス
というように、それぞれ__一件__と__一覧__というように4つに分けて設計します。
[{Image src='nyuuka3.png'}]
これらのクラスの考え方は次の通りです。「一伝票」「一明細」というように異なる単位で呼ばれる物を見つけたら、それらをさらに「一件」「一覧」というふうに分けて考えます。
||モノ||一件||一覧
|入荷伝票(ヘッダ)|○|○
|入荷明細|○|○
一覧クラスと一件クラスの関係が「__コンポジット集約__」になっていないのは、一覧クラスが存在しなくても一件クラスは存在出来るからです。しかし、伝票が存在しないと明細は存在し得ないため、この両者をひもづけている入荷伝票一件と伝票明細一覧との間はコンポジット集約としています。\\
\\
ちなみに上の図を見て、次のような設計でいいのではないかと気付いた人がいるかもしれません。伝票一件が明細一覧も請け負う形です。\\
[{Image src='nyuuka4.png'}]
ここだけの局面を見ればこの設計は正しいのですが、__伝票に依存しない明細一覧オブジェクト__を形成したい場合はうまくいきません。例えば、「伝票には関係せず、商品Aだけの明細一覧を表示する」というような要件に対応できないのです。そのため、伝票明細一覧クラスを必ず設計しておくようにします。\\

!!RDBならば一レコードと一テーブルが別クラス
永続化装置としてRDBを使うことが実際の開発では日常的です。この時には、RDBテーブル一つに対して
*一レコードクラス
*一テーブルクラス (複数レコードを扱う時のクラス)
を必ず対(つい)で設計・実装するようにします。
一レコードクラスは、前項で書いた一件クラスと同じ事です。物や結果の一件分がRDBテーブルの一レコードとして保存されます。\\
一テーブルクラスというのは少し解りにくいのですが、__複数のレコードを扱う__時に使います。複数のレコードというのは最大でそのテーブルの全件を持つことになり、言葉を換えると「一テーブル分」となります。これも前項で出てきた__一覧クラス__と同等です。\\
関係をまとめると、
*一件クラス ⊇ 一レコードクラス
*一覧クラス ⊇ 一テーブルクラス
となります。それぞれ何が違うかというと、一件クラスまたは一覧クラスのうちRDBに永続化する必要のあるものが、一レコードまたは一テーブルという__別の呼び方をされることがある__というだけです。永続化される必要の無いものは別名では呼ばれません。\\
\\
その上で、「テーブルから一件を取得する処理」と「テーブルから一覧を取得する処理」をそれぞれのクラスの中に実装します。\\