質問編集履歴
7
説明の追加
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -35,13 +35,13 @@
|
|
|
35
35
|
着目したテーマ(仕様/場所/目的物 etc.)によって、同じ動きをするプログラミングの関数名が動詞句(メソッド)になることも名詞句(クラス)になることもあるということなのでしょうか。(例えば、juiceStoreクラスにcountJuiceメソッドがあったとして、構成によってはjuiceStoreコンポーネントのjuiceCounterクラスにもなる？)
|
|
36
36
|
|
|
37
37
|
**追記3**
|
|
38
|
-
#6を読んで疑問に思ったのですが、クラスは 「AはBをする」に縛られるのでしょうか。「AがBになる」で作らないほうがいいのでしょうか。例えば、ぬるいジュースから冷たいジュースになるということで normalTempr
|
|
38
|
+
#6を読んで疑問に思ったのですが、クラスは 「AはBをする」に縛られるのでしょうか。「AがBになる」で作らないほうがいいのでしょうか。例えば、ぬるいジュースから冷たいジュースになるということで normalTemperatureJuice クラスと coolingJuice クラスを作るという設計はNGですか。
|
|
39
39
|
|
|
40
40
|
**追記4**
|
|
41
41
|
### 0. 状況整理
|
|
42
42
|
悩む方向が間違っているのかもわかりませんが、悩んでいることをまとめ直しました。
|
|
43
|
-
(1) シナリオの着眼点
|
|
43
|
+
(1) シナリオの着眼点
|
|
44
|
-
(2) クラス(名詞句)/メソッド(動詞句)の使い分け
|
|
44
|
+
(2) クラス(名詞句)/メソッド(動詞句)の使い分け
|
|
45
45
|
(3) 共通クラス/メソッドの置き場とネーミング
|
|
46
46
|
|
|
47
47
|
※青は名詞句 黄緑は動詞句。
|
|
@@ -103,8 +103,8 @@
|
|
|
103
103
|
**疑問⑤-1: 再利用性のあるメソッドの置き場**
|
|
104
104
|
itemクラス内のbanUpsidedownメソッドがdisplayクラスでも再利用性があるという場合はメソッドの場所をitemクラスとdisplayクラスの共用クラスに変更したほうが良いのか。
|
|
105
105
|
|
|
106
|
-
**疑問⑤-2: 分類優先か利用場所優先か**
|
|
106
|
+
**疑問⑤-2: 分類場所優先か利用場所優先か**
|
|
107
|
-
existItemメソッドはitemクラス内で一度も使われない。しかし、itemクラスに分類されるメソッドである。だがdisplayクラスで呼び出されるという場合、existItemメソッドはitemクラス内に置いておいていいのか移動させたほうがいいのか。
|
|
107
|
+
existItemメソッドはitemクラス内で一度も使われない。しかし、itemクラスに分類されるメソッドである。だがdisplayクラスで呼び出されるという場合、existItemメソッドはitemクラス(分類場所)内に置いておいていいのかdisplayクラス(利用場所)へ移動させたほうがいいのか。
|
|
108
108
|
|
|
109
109
|
|
|
110
110
|
|
6
追記4の修正(書き忘れた部分の追加/画像8の差し替え)
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -89,12 +89,17 @@
|
|
|
89
89
|
|
|
90
90
|
**疑問④-1: カプセル化と汎用性**
|
|
91
91
|
オブジェクト指向(カプセル化)と汎用性のあるメソッドに親和性はあるのか。
|
|
92
|
+
汎用性のあるメソッド作るほど、元のクラスの中身が減っていくわけで、そうなると行程がいくつもあり肥大化したクラスを除いて、カプセル化を目指さないほうが無難なのではないか。
|
|
92
93
|
|
|
93
94
|
**疑問④-2: 汎用性のあるメソッドのネーミングと名前空間 1/2**
|
|
94
95
|
共用になりそうなしかし共用になっていないメソッドの配置とネーミングが悩ましいがどうすべきか。shared? option? 一度しか使わないようなメソッドもクラスやメソッドの粒度や抽象度を揃えたとき(シーケンスのレベルや位置が同じとき)共用クラスの中に入るなら、入れるべきなのか。
|
|
95
96
|
|
|
96
97
|
### 5. 共通するメソッドの扱い 2
|
|
98
|
+
itemが自販機にあるのか無いのかを返すexistItemメソッドを追加した。
|
|
99
|
+
itemに関わることなのでitemクラスにあるが、使われるのは自販機の売り切れボタンである。
|
|
100
|
+
(existItem? isExists? itemExists? 語法が正しいのか分かりません。)
|
|
101
|
+
|
|
97
|
-
|
|
98
103
|
**疑問⑤-1: 再利用性のあるメソッドの置き場**
|
|
99
104
|
itemクラス内のbanUpsidedownメソッドがdisplayクラスでも再利用性があるという場合はメソッドの場所をitemクラスとdisplayクラスの共用クラスに変更したほうが良いのか。
|
|
100
105
|
|
5
追記4
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -36,3 +36,71 @@
|
|
|
36
36
|
|
|
37
37
|
**追記3**
|
|
38
38
|
#6を読んで疑問に思ったのですが、クラスは 「AはBをする」に縛られるのでしょうか。「AがBになる」で作らないほうがいいのでしょうか。例えば、ぬるいジュースから冷たいジュースになるということで normalTempreatureJuice クラスと coolingJuice クラスを作るという設計はNGですか。
|
|
39
|
+
|
|
40
|
+
**追記4**
|
|
41
|
+
### 0. 状況整理
|
|
42
|
+
悩む方向が間違っているのかもわかりませんが、悩んでいることをまとめ直しました。
|
|
43
|
+
(1) シナリオの着眼点(#6 #8 #15 #16)
|
|
44
|
+
(2) クラス(名詞句)/メソッド(動詞句)の使い分け (#9)
|
|
45
|
+
(3) 共通クラス/メソッドの置き場とネーミング
|
|
46
|
+
|
|
47
|
+
※青は名詞句 黄緑は動詞句。
|
|
48
|
+
### 1. 設計の大枠
|
|
49
|
+
vendingMachineの大枠を実体面(ハードウェア)から考えた。
|
|
50
|
+
|
|
51
|
+
さらにvendingMachineの大枠を動作面(SVO)から考え直した。
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
**疑問①-1: SVOからのアプローチの語法**
|
|
55
|
+
「vendingMachineのオーナーがjuiceを追加した。」という動作面(SVO)からのアプローチでは、juiceクラスがjuiceSettingのようなネーミングになるのか。storeManagement とstoreManager ではどちらになるのか。一般的なルールはあるのか(そもそも、クラスの命名自体もわかっていない。)
|
|
56
|
+
|
|
57
|
+
**疑問①-2: 着眼点の違うシナリオの混在 1/2 (粒度の等しいクラス)**
|
|
58
|
+
自販機の実体面からアプローチしたクラスとオーナーの動作面からアプローチしたクラスの混在など、着眼点の違いがあるクラスの併存はよくあることなのか、避けていることなのか、例外的に事情があれば許容されるのか。(実体面に着目しても動作面に着目しても、どのようにも書けるのではないかという疑問はこのようなことに端を発している。)シナリオに制約や経験則的に破綻しやすいケースはあるのか。
|
|
59
|
+
|
|
60
|
+
### 2. 汎用性があるクラスへの再編
|
|
61
|
+
juiceクラスは汎用性が無いため、itemクラスに再編した。
|
|
62
|
+
ここではoden(おでん)はfoodのほうが良いのではないかという再々編の余地を残しているがこの設計で大きな影響はない。
|
|
63
|
+
|
|
64
|
+
|
|
65
|
+
**疑問②-1: 着眼点の違うシナリオの混在 2/2 (クラスとメソッド)**
|
|
66
|
+
自販機の実体面から考えられたクラス内にオーナーの動作面から考えられたメソッドという、以下のような構成もありえるのか。
|
|
67
|
+
|
|
68
|
+
処理過程も見方によっては目的となり、また逆もあり、名詞句なのか動詞句なのかの違いだけで内容が同じ関数に関してクラスとメソッドには大きな隔たりが無いように感じているが、どのようにクラスとメソッドの住み分けを進めればいいのか。
|
|
69
|
+
一旦すべての構成をドメイン/クラスとった樹形図のような名前空間に落とし込み、そこからさらに”名前空間をつくる程でもない処理”をメソッドとして扱っても設計できそうだが、メソッドはそのように捉えるべきではないのか。
|
|
70
|
+
|
|
71
|
+
### 3. 共通するメソッドの扱い 1
|
|
72
|
+
各クラスに以下のメソッドが付加された。
|
|
73
|
+
|
|
74
|
+
処理が共通するおまけ飴メソッドのaddRedCandyとaddBlueCandyを一つのaddCandyメソッドにまとめitemクラス配下とした。
|
|
75
|
+
|
|
76
|
+
**疑問③-1: 関連度/粒度/抽象度**
|
|
77
|
+
addCandyメソッドはjuiceクラスとtoyクラスで使われodenクラスには使われないが、配置する場所はitemクラス下で良いのか。それともjuice/oden/toy の粒度や抽象度に合わせてcandyクラスやadditionクラスを作り管理すべきなのか。
|
|
78
|
+
|
|
79
|
+
**疑問③-2: メソッドの拡張性**
|
|
80
|
+
addCandyメソッドにredやblueといった名詞句のタグ付けは可能か。(メソッド(動詞句) = 構成の行き止まりのようなイメージがあるのですがそんなことは無いですか。)addCandyメソッドに拡張性がないのであれば、candyクラスにしてしまうべきか。
|
|
81
|
+
|
|
82
|
+
**疑問③-3: 冗長性**
|
|
83
|
+
構成を厳密にしていくとitem/shared/addition/candy/redクラスを拾うことになるが名前空間や関数名は長くなっても構わないのか。引数は4つまでが良いと何かの本で読んだことがあったが、名前空間も読みやすさなどのルールがあるのか。
|
|
84
|
+
|
|
85
|
+
|
|
86
|
+
### 4. クラスの拡張
|
|
87
|
+
additionクラスをsharedクラスに拡張した。
|
|
88
|
+
banUpsidedown(天地無用)メソッドもoden以外にも使えそうな抽象性のあるメソッドなのでadditionクラスをsharedクラスとしてこれに移動させた。
|
|
89
|
+
|
|
90
|
+
**疑問④-1: カプセル化と汎用性**
|
|
91
|
+
オブジェクト指向(カプセル化)と汎用性のあるメソッドに親和性はあるのか。
|
|
92
|
+
|
|
93
|
+
**疑問④-2: 汎用性のあるメソッドのネーミングと名前空間 1/2**
|
|
94
|
+
共用になりそうなしかし共用になっていないメソッドの配置とネーミングが悩ましいがどうすべきか。shared? option? 一度しか使わないようなメソッドもクラスやメソッドの粒度や抽象度を揃えたとき(シーケンスのレベルや位置が同じとき)共用クラスの中に入るなら、入れるべきなのか。
|
|
95
|
+
|
|
96
|
+
### 5. 共通するメソッドの扱い 2
|
|
97
|
+
|
|
98
|
+
**疑問⑤-1: 再利用性のあるメソッドの置き場**
|
|
99
|
+
itemクラス内のbanUpsidedownメソッドがdisplayクラスでも再利用性があるという場合はメソッドの場所をitemクラスとdisplayクラスの共用クラスに変更したほうが良いのか。
|
|
100
|
+
|
|
101
|
+
**疑問⑤-2: 分類優先か利用場所優先か**
|
|
102
|
+
existItemメソッドはitemクラス内で一度も使われない。しかし、itemクラスに分類されるメソッドである。だがdisplayクラスで呼び出されるという場合、existItemメソッドはitemクラス内に置いておいていいのか移動させたほうがいいのか。
|
|
103
|
+
|
|
104
|
+
|
|
105
|
+
|
|
106
|
+
|
4
文法のミス/読み間違えの修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -35,4 +35,4 @@
|
|
|
35
35
|
着目したテーマ(仕様/場所/目的物 etc.)によって、同じ動きをするプログラミングの関数名が動詞句(メソッド)になることも名詞句(クラス)になることもあるということなのでしょうか。(例えば、juiceStoreクラスにcountJuiceメソッドがあったとして、構成によってはjuiceStoreコンポーネントのjuiceCounterクラスにもなる？)
|
|
36
36
|
|
|
37
37
|
**追記3**
|
|
38
|
-
#6を読んで疑問に思ったのですが、クラスは 「AはBをする」に縛られるのでしょうか。「AがBになる」で作らないほうがいいのでしょうか。例えば、ぬるいジュースから冷たいジュースになるということで normalTempreatureJuice クラスと coolJuice クラスを作るという設計はNGですか。
|
|
38
|
+
#6を読んで疑問に思ったのですが、クラスは 「AはBをする」に縛られるのでしょうか。「AがBになる」で作らないほうがいいのでしょうか。例えば、ぬるいジュースから冷たいジュースになるということで normalTempreatureJuice クラスと coolingJuice クラスを作るという設計はNGですか。
|
3
追記3
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -27,9 +27,12 @@
|
|
|
27
27
|
それとも何か基準やルールでもあるのでしょうか。
|
|
28
28
|
着目するところやコツがあれば教えていただきたいです。
|
|
29
29
|
|
|
30
|
-
|
|
30
|
+
**追記1**
|
|
31
31
|
"どうにでも" というのは少々乱暴な言い方でした。すみません。
|
|
32
32
|
言いたいことは、自動販売機の例でいうところの、仕様に着目しても場所に着目しても目的物に着目しても分かりやすさと保守性があれば、どのような設計を選んでも構わないのかということです。
|
|
33
33
|
|
|
34
|
-
|
|
34
|
+
**追記2**
|
|
35
35
|
着目したテーマ(仕様/場所/目的物 etc.)によって、同じ動きをするプログラミングの関数名が動詞句(メソッド)になることも名詞句(クラス)になることもあるということなのでしょうか。(例えば、juiceStoreクラスにcountJuiceメソッドがあったとして、構成によってはjuiceStoreコンポーネントのjuiceCounterクラスにもなる？)
|
|
36
|
+
|
|
37
|
+
**追記3**
|
|
38
|
+
#6を読んで疑問に思ったのですが、クラスは 「AはBをする」に縛られるのでしょうか。「AがBになる」で作らないほうがいいのでしょうか。例えば、ぬるいジュースから冷たいジュースになるということで normalTempreatureJuice クラスと coolJuice クラスを作るという設計はNGですか。(#1よりcoolJuiceの例は汎用性がないとのことですが)
|
2
追記
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -27,7 +27,9 @@
|
|
|
27
27
|
それとも何か基準やルールでもあるのでしょうか。
|
|
28
28
|
着目するところやコツがあれば教えていただきたいです。
|
|
29
29
|
|
|
30
|
-
追記
|
|
30
|
+
// 追記
|
|
31
31
|
"どうにでも" というのは少々乱暴な言い方でした。すみません。
|
|
32
|
-
言いたいことは、自動販売機の例でいうところの、仕様に着目しても場所に着目しても目的物に着目しても
|
|
32
|
+
言いたいことは、自動販売機の例でいうところの、仕様に着目しても場所に着目しても目的物に着目しても分かりやすさと保守性があれば、どのような設計を選んでも構わないのかということです。
|
|
33
|
+
|
|
33
|
-
|
|
34
|
+
// 追記2
|
|
35
|
+
着目したテーマ(仕様/場所/目的物 etc.)によって、同じ動きをするプログラミングの関数名が動詞句(メソッド)になることも名詞句(クラス)になることもあるということなのでしょうか。(例えば、juiceStoreクラスにcountJuiceメソッドがあったとして、構成によってはjuiceStoreコンポーネントのjuiceCounterクラスにもなる？)
|
1
追記
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
設計は何に着目すればいいのでしょうか。
|
|
3
3
|
オブジェクト指向などの本も読んでみましたがよくわからないです。
|
|
4
4
|
|
|
5
|
-
自動販売機を例にとると
|
|
5
|
+
vendingMachine (自動販売機) を例にとると
|
|
6
6
|
|
|
7
7
|
① 仕様に着目 (動詞 メソッド風?)
|
|
8
8
|
(1) storeJuice ジュースを保管する
|
|
@@ -27,4 +27,7 @@
|
|
|
27
27
|
それとも何か基準やルールでもあるのでしょうか。
|
|
28
28
|
着目するところやコツがあれば教えていただきたいです。
|
|
29
29
|
|
|
30
|
-
|
|
30
|
+
追記
|
|
31
|
+
"どうにでも" というのは少々乱暴な言い方でした。すみません。
|
|
32
|
+
言いたいことは、自動販売機の例でいうところの、仕様に着目しても場所に着目しても目的物に着目しても
|
|
33
|
+
分かりやすさと保守性があれば、どのような設計を選んでも構わないのかということです。
|