This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

単位が異なれば同じ物でも異なるクラスになる#

「一個売りしているリンゴ」をシステムで扱う場合、どのような属性が必要になるかを考えてみます。

1. 品種
2. 重さ
3. 売り値
4. 入荷日

などが考えられます。
それでは、「一山売りしているリンゴ」はどうでしょうか?

1. 品種 (同じ山には同じ品種を乗せる前提)
2. 重さ (一山あたりの総重量)
3. 売り値 (一山あたりの総額)
4. 個数

上記を較べてみると、同じリンゴでも違いのある事が解ります。処理を考えてみるとさらに明らかになります。
「一山売りしているリンゴ」では、「一個あたりの売り値(平均の売り値)を返す」というメソッドがすぐに思い浮かびます。
これらから解るように、「リンゴ」というクラスが設計段階、特に概念モデルで出てきても、それが一個なのか一山なのかを確定させないと正しいクラスとして設計できません。裏を返すと、同じリンゴであっても、それを扱う単位が異なれば異なるクラスとして設計する必要があるということです。

実際のシステムでは一件クラスと一覧クラス#

単位が異なると言っても、実際のシステムではどう考えればいいのでしょう? 答えは簡単で、「『一件』と『一覧』は異なるクラスとして設計・実装する」です。『件』と『覧』というふうに単位が異なるからです。
例えば業務要件を聞いている中で「顧客会社クラス」が出てきた場合は、

1. 「顧客会社一件クラス」
2. 「顧客会社一覧クラス」

の二つの可能性があります。 顧客会社を一件のみ、つまり一会社として扱う時のクラスが「顧客会社一件クラス」です。複数件として、つまり顧客会社を一覧として扱う場合は「顧客会社一覧クラス」を作ります。一覧クラスは一件クラスを内部で複数持つように設計します。ほとんどのシステムにおいて両方必要です。

要件の中に出てくる単位を見逃さない#

前項までで解るように、単位は非常に重要です。ここで言う単位というのは物理学で言うものではなく、業務を遂行する人たちがあるものをひとかたまりとして扱う大きさのことです。

• 一伝票
• 一明細
• 一会社
• 一箱
• 一取引

など色々ありますが、人間が何かをひとかたまりとして扱い、そのかたまりの種類が異なる場合には必ず単位が異なります。もちろん、非常に汎用的な「一個」という単位はあちこちで出てきますが、その場合は「何々一個」というように聞き分けて設計していけば問題ありません。

RDBならば一レコードと一テーブルが別クラス#

永続装置としてRDBを使うことが実際の開発では日常的です。この時には、RDBテーブル一つに対して

• 一レコードクラス
• 一テーブルクラス (複数レコードを扱う時のクラス)

を必ず対(つい)で設計・実装するようにします。 一テーブルクラスというのは少し解りにくいのですが、複数のレコードを扱う時に使います。複数のレコードというのは最大でそのテーブルの全件を持つことになり、言葉を換えると「一テーブル分」となります。

単位が異なるとクラスが異なるという原則がこれで解ると思います。