ページ本文 ファイル添付 (10) ページ情報

添付ファイルの追加

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

添付ファイル一覧

Kind Attachment Name Size Version Date Modified Author Change note
png
 inventory.png 5.2 kB 1 03-1-2012 00:06 ytp
png
 inventory2.png 1.9 kB 1 03-1-2012 00:07 ytp
png
 order_amount.png 20.0 kB 1 09-1-2012 22:22 ytp
png
 order_classes10.png 8.8 kB 1 09-1-2012 22:22 ytp
png
 order_classes11.png 17.8 kB 1 09-1-2012 22:22 ytp
png
 order_methods.png 14.2 kB 2 31-12-2011 22:38 ytp
png
 receipt.png 6.1 kB 1 02-1-2012 21:25 ytp
png
 receipt2.png 1.8 kB 1 03-1-2012 00:07 ytp
png
 receipt_inventory.png 3.3 kB 1 03-1-2012 00:53 ytp
png
 receipt_inventory_seq.png 11.5 kB 1 03-1-2012 20:17 ytp

This page (revision-19) was last changed on 25-7-2014 20:58 by ytp

This page was created on 30-8-2011 15:57 by ytp

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 1 changed 2 lines
★このページは書きかけです
!!!どのメソッドをどのクラスに記述するのかの原則は2つだけ
!!!メソッド実装場所の原則は2つだけ
At line 17 changed 2 lines
#ヘッダと明細のような上下関係がクラスにある場合、必要な属性の最上位に当たるクラスのメソッドとする。
#クラスの関係が対等または並列である場合、第3のクラスを作ってそのメソッドとする。(Mediatorパターンの利用)
#ヘッダと明細のような上下関係がクラスにある場合、必要な属性の最上位に当たるクラスのメソッドとする
#クラスの関係が対等または並列である場合、第3のクラスを作ってそのメソッドとする(Mediatorパターンの利用)
At line 25 changed 3 lines
をどのクラスに実装すべきかを検討してみます。\\
クラス図は次です。\\
[order_methods.png]\\
をどのクラスに実装すべきかを検討してみましょう。分析クラス図は次です。\\
[order_classes10.png]\\
At line 29 changed one line
#各明細ごとの受注額を計算する(受注個数 × 商品単価)
#明細ごとの受注額を計算する(受注個数 × 商品単価)
At line 33 changed 7 lines
*金額
*商品単価
*受注個数
*受注明細
*受注明細一覧
*受注伝票
と6つありますが、受注総額を返すメソッドはどのクラスで実装するべきでしょうか?\\
#金額
#商品単価
#商品単価一覧
#受注個数
#受注明細
#受注明細一覧
#受注伝票
と7つありますが、受注総額を返すメソッドはどのクラスで実装するべきでしょうか?\\
At line 43 added one line
%%sup ※シーケンス説明の__*__印は繰り返す処理を意味します。/%\\
At line 63 added 73 lines
結果的に設計クラス図は次のようになります。\\
[order_classes11.png]\\
!!第3のクラスを作ってそのメソッドとする(Mediatorパターン)
2つのクラスに上下関係にあたるものがない場合、その2つを仲介する3つ目のクラスを作ります。この原則は、Gofのデザインパターンにおける__Mediatorパターン__に応用されています。\\
2つのクラスの関係が密接ではない場合に相手のメソッドを直接呼び出す設計をしていると、どちらかのクラスの仕様変更によってもう一方のクラスも修正しなくてはならない事態に陥りがちです。\\
商品の入荷と在庫を例に考えてみます。必要になるのは、
*入荷伝票
*在庫商品一覧
の2つです。(下図)\\
[receipt.png]\\
[inventory.png]\\
実際の業務では、入荷された商品を倉庫に保存することになります。この時、システム的には入荷伝票を基に在庫数を増やす処理が必要になりますが、この処理(メソッド)をどのクラスで実装するかというのがこの節での命題です。\\
考えられるのは、
#入荷伝票クラス
#在庫商品一覧クラス
#第3のクラス
の3通りです。\\
\\
入荷伝票に実装する場合は、在庫商品一覧クラスをそのメソッドに引数として渡すことになります。\\
[receipt2.png]\\
この時そのメソッド内では、
#入荷明細一覧内の入荷明細の数だけ以下を繰り返す
#在庫商品インスタンスを生成する
#商品、個数、ロケーション、入庫日付を在庫商品に設定する
#在庫商品インスタンスを在庫商品一覧インスタンスに追加する
というように実装することになります。入荷伝票クラスは在庫商品一覧クラスの仕様を熟知している必要があります。\\
\\
逆に在庫商品一覧クラスで実装する場合は、入荷伝票クラスをそのメソッドに引数として渡すことになります。\\
[inventory2.png]\\
この時そのメソッド内では、
#入荷伝票から入荷明細一覧を取り出す
#入荷明細の数だけ以下を繰り返す
#在庫商品インスタンスを生成する
#商品、個数、ロケーション、入庫日付を在庫商品に設定する
#在庫商品インスタンスを自身(在庫商品一覧)のインスタンスに追加する
というように実装することになります。今度は逆に、在庫商品一覧クラスは入荷伝票クラスの仕様を熟知している必要があります。\\
\\
入荷の結果である入荷伝票と在庫の結果である在庫商品一覧が密接に結びついても問題ない場合は上記のいずれかでも構わないのですが、相手側クラスの仕様に変更があった場合はその影響を免れません。\\
こういう場合は、
*第3のクラス
を設計しておく方が、片方のクラスの仕様変更を相手クラスに影響させずに済みます。Gofのデザインパターンにおける
*Mediator(仲介者)パターン
はこの原則を応用したものです。\\
[receipt_inventory.png]\\
この時の処理シーケンスは次のようになります。\\
[receipt_inventory_seq.png]\\
%%sup ※シーケンス説明の__*__印は繰り返す処理を意味します。/%\\
入荷伝票と在庫商品一覧の仲介者として入荷在庫クラスが働いていることが解ります。この手法を理解する上での注意点は、入荷伝票と在庫商品一覧の両方のデータを持つクラスとして入荷在庫クラスを設計することです。\\
単なる仲介者として設計してしまうと「仲介する」処理だけを実装することになります。そうではなく、
*入荷伝票と在庫商品一覧の両方のデータをひとかたまりとしたクラスである
と強く意識して設計して下さい。\\
\\
この節の冒頭にも書きましたが、入荷伝票と在庫商品一覧をあえて強く結びつけたい場合はいずれかのメソッドとして設計して下さい。
#仲介者を通じて疎結合にするのか
#直接呼び出す密結合にするのか
いずれの方法を採るのかは設計者の意図によって変わってきます。しかし迷った場合は第2の原則に従いましょう。\\
!!まとめ
どのメソッドをどのクラスで実装するのかの原則は2つ。
#ヘッダと明細のような上下関係がクラスにある場合、必要な属性の最上位に当たるクラスのメソッドとする
#クラスの関係が対等または並列である場合、第3のクラスを作ってそのメソッドとする(Mediatorパターンの利用)
!!コラム
メソッド実装の原則が2つしかないというのはにわかには信じがたいかも知れません。複雑な関連を持つクラス図を考えるともっとたくさんありそうだと感じるのも無理はありません。\\
しかし複雑な関連も紐解いていけば、最終的には2つのクラスの関係に分解できます。その2つのクラスにまたがる処理を考える場合、その2つのクラスが
#上下関係がある
#並列関係になっている
の2パターンに分類できるのは理解できることでしょう。\\
このように、一見複雑なものもその原則は単純であることが多いのです。複雑に絡み合った結果であるパターンの奥には単純な原則が隠れています。それを見抜く力を付けることが一番大切だと私は感じています。\\
\\
次: [業務シナリオで考える]
Version Date Modified Size Author Changes ... Change note
19 25-7-2014 20:58 3.888 kB ytp to previous
18 11-3-2012 23:19 3.902 kB ytp to previous | to last
17 09-1-2012 22:25 3.902 kB ytp to previous | to last
16 09-1-2012 03:07 3.893 kB ytp to previous | to last
15 09-1-2012 02:59 3.852 kB ytp to previous | to last
14 09-1-2012 02:52 3.843 kB ytp to previous | to last
13 03-1-2012 23:57 3.791 kB ytp to previous | to last
12 03-1-2012 23:42 3.766 kB ytp to previous | to last
11 03-1-2012 23:41 3.766 kB ytp to previous | to last
10 03-1-2012 22:52 3.781 kB ytp to previous | to last
9 03-1-2012 00:44 2.894 kB ytp to previous | to last
8 03-1-2012 00:39 2.839 kB ytp to previous | to last
7 02-1-2012 22:28 2.793 kB ytp to previous | to last
6 01-1-2012 01:19 1.854 kB ytp to previous | to last
5 31-12-2011 23:25 1.607 kB ytp to previous | to last
4 10-9-2011 12:02 1.594 kB ytp to previous | to last
3 31-8-2011 01:21 1.592 kB ytp to previous | to last
2 30-8-2011 22:20 0.926 kB ytp to previous | to last
1 30-8-2011 15:57 0.626 kB ytp to last
« This page (revision-19) was last changed on 25-7-2014 20:58 by ytp