質問編集履歴
1
文章整理
test
CHANGED
File without changes
|
test
CHANGED
@@ -32,46 +32,6 @@
|
|
32
32
|
|
33
33
|
|
34
34
|
|
35
|
-
どうしてUMLはこういう書き方、というか、最終的な形から親をたどっていく...というような視点を持っているのでしょうか。
|
36
|
-
|
37
|
-
多重継承あたりにヒントがあるような気がしているのですが、extendsは単一、implementsは複数を許可していることから考えると、
|
38
|
-
|
39
|
-
```
|
40
|
-
|
41
|
-
[親クラス]→[注目したいクラス]←[interface1]
|
42
|
-
|
43
|
-
←[interface2]
|
44
|
-
|
45
|
-
```
|
46
|
-
|
47
|
-
のほうが、
|
48
|
-
|
49
|
-
```
|
50
|
-
|
51
|
-
[interface1] ←
|
52
|
-
|
53
|
-
[interface2] ← [注目したいクラス]
|
54
|
-
|
55
|
-
[親クラス] ←
|
56
|
-
|
57
|
-
```
|
58
|
-
|
59
|
-
よりもすっきりわかりやすい気がするのですが....
|
60
|
-
|
61
|
-
(Interfaceにぶら下がるように子クラスを書くと、それをimplementsしているクラスが増えるほど
|
62
|
-
|
63
|
-
図が手狭になってしまう。Interfaceは単純に定義だけで中身はなにもないのだから、
|
64
|
-
|
65
|
-
主役か脇役かでいったら脇役であり、主役であるクラスを第一に注目対象として
|
66
|
-
|
67
|
-
その関係性を際立たせるべきでは?という考えです)
|
68
|
-
|
69
|
-
|
70
|
-
|
71
|
-
|
72
|
-
|
73
|
-
なんだかごちゃごちゃになってしまいましたが、
|
74
|
-
|
75
35
|
UMLクラス図の "親を辿っていく" 考え方の発祥経緯にお詳しい方、
|
76
36
|
|
77
37
|
どうぞお手ほどきをお願いいたします。
|