回答編集履歴
6
説明が追加されたので修正
test
CHANGED
|
@@ -41,8 +41,9 @@
|
|
|
41
41
|
別にdisplayクラスの内部(静的)クラスも作ります。
|
|
42
42
|
両方に完全に共通するなら、よりpublicな別パッケージに出します。
|
|
43
43
|
|
|
44
|
-
疑問⑤-2: 分類優先か利用場所優先か
|
|
44
|
+
疑問⑤-2: 分類場所優先か利用場所優先か
|
|
45
|
-
existI
|
|
45
|
+
existsInVendingMachineくらいの意味なんですね。もしそうならdisplayには使えません。
|
|
46
|
+
displayからitemへの関連/依存くらいに設計するかと思います。
|
|
46
47
|
|
|
47
48
|
#### 感想
|
|
48
49
|
悩むくらいなら手を動かして、全ケース見てしまいましょう。疑問点がいくらか狭まるはずです。ある程度自力で解を得られた段階で他人に確認してみましょう(ある程度できてますが)。十分な検討なしに疑問の全てを他人に聞いていても成長しません。
|
5
質問3/14追記分について意見更新
test
CHANGED
|
@@ -7,3 +7,44 @@
|
|
|
7
7
|
|
|
8
8
|
「仕様に着目しても場所に着目しても目的物に着目しても」に、何か意味があるようには思えませんでした。不都合がないならどうでもいいです。
|
|
9
9
|
よくある自販機問題は、分析/設計がそれぞれどういうものかを体験してもらう程度の意味合いしかないと思います。
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
#### 質問の3/14追記分について
|
|
13
|
+
要件がないのに設計の良し悪しもなく、実装した場合具体的な不都合があるケースだけ除外できればいいです。
|
|
14
|
+
|
|
15
|
+
疑問①-1: SVOからのアプローチの語法
|
|
16
|
+
一般的なルールはありません。SVOとかどうでもいいですが、分かりやすいと思う名前にしましょう。
|
|
17
|
+
個人的な意見では、**他のに合わせてください**というだけ。ルールや名前自体も**統一**は必要です。
|
|
18
|
+
|
|
19
|
+
疑問①-2: 着眼点の違うシナリオの混在 1/2 (粒度の等しいクラス)
|
|
20
|
+
着眼点とか見え方とかあんまり気にしないでいい。
|
|
21
|
+
とにかく他と同じように書ける部分は**可能な限り全て**そう書いてくれればいいだけ。
|
|
22
|
+
無理なく汎化できるなら括りだせばいいだけ。
|
|
23
|
+
破綻するならモデリングをやり直せばいいだけ。
|
|
24
|
+
|
|
25
|
+
疑問②-1: 着眼点の違うシナリオの混在 2/2 (クラスとメソッド)
|
|
26
|
+
疑問③-1: 関連度/粒度/抽象度
|
|
27
|
+
いろいろな書き方あるけど別に書きたいように(保守性が高いと思う形に)書けばよく、正直どうでもいい。
|
|
28
|
+
|
|
29
|
+
ここまで、どういう設計が綺麗と思うか？という話なので、主観にしかならない気がします。
|
|
30
|
+
実害がなければ何でもいいです。
|
|
31
|
+
とにかく理由がなければ分かりやすさのために**統一**だけ意識してください。
|
|
32
|
+
|
|
33
|
+
疑問④-1: カプセル化と汎用性
|
|
34
|
+
あります。
|
|
35
|
+
|
|
36
|
+
疑問④-2: 汎用性のあるメソッドのネーミングと名前空間 1/2
|
|
37
|
+
好きにしていいです。
|
|
38
|
+
|
|
39
|
+
疑問⑤-1: 再利用性のあるメソッドの置き場
|
|
40
|
+
itemクラスの内部(静的)クラスでいいです。
|
|
41
|
+
別にdisplayクラスの内部(静的)クラスも作ります。
|
|
42
|
+
両方に完全に共通するなら、よりpublicな別パッケージに出します。
|
|
43
|
+
|
|
44
|
+
疑問⑤-2: 分類優先か利用場所優先か
|
|
45
|
+
existItemの意味が分かりません。
|
|
46
|
+
|
|
47
|
+
#### 感想
|
|
48
|
+
悩むくらいなら手を動かして、全ケース見てしまいましょう。疑問点がいくらか狭まるはずです。ある程度自力で解を得られた段階で他人に確認してみましょう(ある程度できてますが)。十分な検討なしに疑問の全てを他人に聞いていても成長しません。
|
|
49
|
+
|
|
50
|
+
ここで書くのはどうかとも思いますが、本に書いてある内容は考え方など、大抵アイデアレベルの話だと思います。実際にやれば問題点が山のように積まれるので、知識として活用し、完全に適合するケースだけいいとこ取りできればOK。普通にやっても上手くできる人たちが、さらによくするために考えたアイデアくらいに思ってくれればいいような気がします。ただし挑戦的なプロジェクトで、そういう人たちが集まって何か作るなら、要件外のあらゆるケースを考え尽くした最善の方法(でも大抵一番シンプルなのになる)を考えてください。
|
4
自販機問題に対しての考えを付記
test
CHANGED
|
@@ -6,4 +6,4 @@
|
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
「仕様に着目しても場所に着目しても目的物に着目しても」に、何か意味があるようには思えませんでした。不都合がないならどうでもいいです。
|
|
9
|
-
|
|
9
|
+
よくある自販機問題は、分析/設計がそれぞれどういうものかを体験してもらう程度の意味合いしかないと思います。
|
3
質問に追記された内容について補足
test
CHANGED
|
@@ -2,3 +2,8 @@
|
|
|
2
2
|
悪い実装はコストに跳ね返ってきます。
|
|
3
3
|
|
|
4
4
|
どうにでも書けてしまうように見えて、こう書くと実装時に破綻したり、分かりにくかったり、遅かったり、将来書き換えにくくなったりということがあります。そういう問題をできるだけ避けるには、コードのパターンとしてこう書くべき、という言い方もできるのですが、設計でも防げるのではないでしょうか。そう思ってくれれば、設計だと「どうにでも書けてしまう」ということはないかと思います(ある程度自由度はありますが)。
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
「仕様に着目しても場所に着目しても目的物に着目しても」に、何か意味があるようには思えませんでした。不都合がないならどうでもいいです。
|
|
9
|
+
|
2
よく見たら言い回しがくどかったので変更した。
test
CHANGED
|
@@ -1,5 +1,4 @@
|
|
|
1
1
|
設計に特にルールはありませんが、悪い設計からは悪い実装しか生まれません。
|
|
2
2
|
悪い実装はコストに跳ね返ってきます。
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
しかし、仕様を実装に落とし込む際の、関係者全員が理解可能な中間的な文書＝設計でも、同様にそういう問題を回避するために利用できます。そう思ってくれれば、設計だと「どうにでも書けてしまう」ということはないかと思います(ある程度自由度はありますが)。
|
|
3
|
+
|
|
4
|
+
どうにでも書けてしまうように見えて、こう書くと実装時に破綻したり、分かりにくかったり、遅かったり、将来書き換えにくくなったりということがあります。そういう問題をできるだけ避けるには、コードのパターンとしてこう書くべき、という言い方もできるのですが、設計でも防げるのではないでしょうか。そう思ってくれれば、設計だと「どうにでも書けてしまう」ということはないかと思います(ある程度自由度はありますが)。
|
1
文章が分かりにくかったので修正。
test
CHANGED
|
@@ -1,4 +1,5 @@
|
|
|
1
1
|
設計に特にルールはありませんが、悪い設計からは悪い実装しか生まれません。
|
|
2
2
|
悪い実装はコストに跳ね返ってきます。
|
|
3
3
|
どうにでも書けてしまうように見えて、こう書くと実装時に破綻したり、分かりにくかったり、遅かったり、将来書き換えにくくなったりということがあります。
|
|
4
|
+
上記のような問題をできるだけ避けるべく、コードのパターンとしてこう書くべき、という言い方もできます。
|
|
4
|
-
|
|
5
|
+
しかし、仕様を実装に落とし込む際の、関係者全員が理解可能な中間的な文書＝設計でも、同様にそういう問題を回避するために利用できます。そう思ってくれれば、設計だと「どうにでも書けてしまう」ということはないかと思います(ある程度自由度はありますが)。
|