| At line 13 changed 2 lines |
| 「一山売りしているリンゴ」では、「__一個あたりの売り値(平均の売り値)を返す__」というメソッドがすぐに思い浮かびます。\\ |
| これらから解るように、「リンゴ」というクラスが設計段階、特に概念モデルで出てきても、それが一個なのか一山なのかを確定させないと正しいクラスとして設計できません。裏を返すと、同じリンゴであっても、それを扱う__単位が異なれば異なるクラス__として設計する必要があるということです。\\ |
| 「一山売りしているリンゴ」では、 |
| *一個あたりの売り値(平均の売り値)を返す |
| というメソッドがすぐに思い浮かびます。\\ |
| これらから解るように、「リンゴ」というクラスが設計段階、特に分析クラス図で出てきても、 |
| *それが一個なのか一山なのかを確定させないと正しいクラスとして設計できない |
| のです。裏を返すと、同じリンゴであっても、 |
| *それを扱う単位が異なれば異なるクラスになる |
| ことを理解して設計する必要があるということです。\\ |
| At line 29 changed one line |
| このページの見出しにあるリンゴ一個とリンゴ一山」は、実際のシステムではどう考えればいいのでしょう? 答えは簡単で、__「『一件』と『一覧』は異なるクラスとして設計・実装する__」です。『一件』がリンゴ一個に相当し、『一覧』がリンゴ一山に相当します。\\ |
| このページの見出しにある「リンゴ一個とリンゴ一山」を実際のシステムではどう考えればいいのでしょう? 答えは簡単で、 |
| *『一件』と『一覧』は異なるクラスとして設計・実装する |
| です。『一件』がリンゴ一個に相当し、『一覧』がリンゴ一山に相当します。\\ |
| At line 34 changed one line |
| 顧客会社を一件のみ、つまり一会社として扱う時のクラスが「顧客会社一件クラス」です。__顧客会社を複数件で__、つまり一覧として扱う場合は「顧客会社一覧クラス」を作ります。一覧クラスは一件クラスを__内部で複数持つ__ように設計します。ほとんどのシステムにおいて両方必要です。\\ |
| 顧客会社を一件のみ、つまり一会社として扱う時のクラスが「顧客会社一件クラス」です。顧客会社を複数件で、つまり__一覧として扱う場合は「顧客会社一覧クラス」を作ります__。そして、__ |
| *一覧クラスは一件クラスを内部で複数持つ |
| ように設計します。ほとんどのシステムにおいてその両方が必要です。\\ |
| At line 42 changed one line |
| は、「一伝票」と「一明細」というように単位が異なるので別クラスとして定義します。伝票は、ある仕入れ先からのある日の入荷物全体を表現しています。__伝票ヘッダ__とも言われます。明細は商品単位の情報を持っており、一伝票が複数の明細を持つ形です。 |
| は、「一伝票」と「一明細」というように__単位が異なるので別クラスとして定義__します。伝票は、ある仕入れ先からのある日の入荷物全体を表現しています。伝票ヘッダとも言われます。明細は商品単位の情報を持っており、一伝票が複数の明細を持つ形です。 |
| At line 50 changed one line |
| というように、それぞれ__一覧__と__一件__というように4つに分けて設計します。 |
| というように、それぞれ__一覧__と__一件__というように4つに分けて考えます。\\ |
| At line 56 changed one line |
| 一覧クラスと一件クラスの関係が「__コンポジット集約__」になっていないのは、一覧クラスが存在しなくても一件クラスは存在出来るからです。しかし、伝票が存在しないと明細は存在し得ないため、この両者をひもづけている入荷伝票一件と伝票明細一覧との間はコンポジット集約としています。\\ |
|
| At line 58 changed one line |
| ちなみに上の図を見て、次のような設計でいいのではないかと気付いた人がいるかもしれません。伝票一件が明細一覧も兼ねる形です。\\ |
| しかし上の図を見て、次のような設計でいいのではないかと気付いた人がいるかもしれません。__伝票一件が明細一覧も兼ねる形__です。\\ |
| At line 60 changed one line |
| ここだけの局面を見ればこの設計は正しいのですが、__伝票に依存しない明細一覧オブジェクト__を形成したい場合はうまくいきません。例えば、「全ての伝票の中から、商品Aだけの明細一覧を表示する」というような要件に対応できないのです。そのため、伝票明細一覧クラスを必ず設計しておくようにします。\\ |
| 実は、 |
| *入荷伝票クラスは入荷明細に対する一覧クラスを兼ねている |
| のです。また、\\ |
| *伝票に依存しない明細一覧オブジェクトを形成したい |
| 場合に上記ではうまくいきません。例えば、 |
| *全ての伝票の中から商品Aだけの明細一覧を表示する |
| というような要件に対応できないのです。入荷明細一覧クラスから参照できる入荷伝票が1つしかないことになり、 |
| *入荷明細に商品Aを持つ複数の入荷伝票 |
| という関係を表現できません。 |
| このため、入荷伝票が入荷明細一覧クラスを兼ねる形で設計しておくようにします。\\ |
| それとは別に、入荷伝票とは独立して入荷明細を一覧化するためのクラスも設計します。次のような形です。\\ |
| [nyuuka8.png]\\ |
| 上記図のカージナリティに注意して下さい。\\ |
| *入荷伝票一件クラスと入荷明細一件クラスは「1:1以上」 |
| *入荷明細一覧クラスと入荷明細一件クラスは「1:0以上」 |
| となります。入荷明細が1件も存在しない入荷伝票は許されません。一方で、「商品Aを持つ入荷明細」を検索した場合の結果が0件となることはあり得ます。 |
| At line 67 changed 2 lines |
| 一レコードクラスは前項で書いた一件クラスと同じ事です。物や結果の一件分がRDBテーブルの一レコードとして保存されます。\\ |
| 一テーブルクラスというのは少し解りにくいのですが、__複数のレコードを扱う__時に使います。複数のレコードというのは最大でそのテーブルの全件を持つことになり、言葉を換えると「一テーブル分」となります。これも前項で出てきた__一覧クラス__と同等です。\\ |
| __一レコードクラスは前項で書いた一件クラスと同じ事__です。物や結果の一件分がRDBテーブルの一レコードとして保存されます。\\ |
| 一テーブルクラスというのは少し解りにくいのですが、複数のレコードを扱う時に使います。\\ |
| *複数のレコードというのは最大でそのテーブルの全件を持つ |
| ことになり、言葉を換えると |
| *一テーブル分 |
| となります。これも前項で出てきた__一覧クラス__と同等です。\\ |
| At line 72 changed 4 lines |
| となります。それぞれ何が違うかというと、一件クラスまたは一覧クラスのうちRDBに永続化する必要のあるものが、一レコードまたは一テーブルという__別の呼び方をされることがある__というだけです。永続化される必要の無いものは別名では呼ばれません。\\ |
| \\ |
| その上で、「テーブルから一件を取得する処理」と「テーブルから一覧を取得する処理」をそれぞれのクラスの中に実装します。次のような形です。\\ |
| [{Image src='nyuuka5.png'}] |
| となります。それぞれ何が違うかというと、一件クラスまたは一覧クラスのうちRDBに永続化する必要のあるものが一レコードまたは一テーブルという__別の呼び方をされることがある__というだけです。永続化される必要の無いものは別名では呼ばれません。\\ |
| その上で、 |
| *RDBから一件を取得する処理 |
| *RDBから一覧を取得する処理 |
| をそれぞれのクラスの中に実装します。次のような形です。 |
| [nyuuka5.png]\\ |
| この際、入荷伝票一件クラスのRDBから一件を取得する処理の中で、 |
| *ひも付く複数件の入荷明細を取得する処理 |
| も実装します。\\ |
| At line 82 changed one line |
| ソートに限らず、業務的な処理も一覧の中に実装します。例えば、「最も注文数の多かった商品明細を返す」という処理です。 |
| ソートに限らず、業務的な処理も一覧の中に実装します。例えば、「数量の一番多い明細を返す」という処理です。 |
| At line 119 added 4 lines |
| !!まとめ |
| *単位が換われば異なるクラスにする |
| *複数件を扱う場合は一覧クラスを必ず作る |
|
