回答編集履歴
2
微修正
answer
CHANGED
|
@@ -72,5 +72,5 @@
|
|
|
72
72
|
|
|
73
73
|
しかし、これは単なるバグです。InstrumentedHashSet<E>::addAll()は`addCount += c.size();`してはいけないのに、仮想関数の意味を理解しないままやってしまったバグです。
|
|
74
74
|
|
|
75
|
-
要するに、
|
|
75
|
+
要するに、バグりやすいので継承は使わない方が良いと言っていることになります。
|
|
76
76
|
確かに継承は単にメンバ変数として実装するより技術的に難易度高いので、素人は使うなって間違ってはいないですが、いくらなんでもそれは読者をバカにしすぎてないでしょうか？
|
1
追記
answer
CHANGED
|
@@ -17,4 +17,60 @@
|
|
|
17
17
|
複数のインスタンスがあることが自然な時はメンバ変数
|
|
18
18
|
|
|
19
19
|
でも、あまり意識したことないです。本質的に異なるので悩むことはほとんどないのです。
|
|
20
|
-
継承はよく言われるように原則としてis_a関係です。PhoneをWorkerが継承するってことは"Worker is a Phone."（労働者は電話機の一種）ということになります。悩むまでもなく継承はありえないですね。
|
|
20
|
+
継承はよく言われるように原則としてis_a関係です。PhoneをWorkerが継承するってことは"Worker is a Phone."（労働者は電話機の一種）ということになります。悩むまでもなく継承はありえないですね。
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
【追記】（長文失礼）
|
|
24
|
+
「コンポジション」について何か変な印象を受ける解説が多々あるので、追いかけてみました。
|
|
25
|
+
|
|
26
|
+
どうも「[オブジェクト指向プログラミングへの道 5日目：オブジェクトコンポジション](http://www.fujitsu.com/jp/solutions/infrastructure/dynamic-infrastructure/sdas/technology/java-oo/05-object-composition/)」や「[【Effective Java】項目１６：継承よりコンポジションを選ぶ](http://hjm333.hatenablog.com/entry/2015/09/16/003849)」に問題がありそうです。（後者はEffective Javaの項目16が開示されていなかったので、Effective Javaへの突っ込みのために引用させて頂きました。）
|
|
27
|
+
|
|
28
|
+
##### オブジェクト指向プログラミングへの道 5日目：オブジェクトコンポジション
|
|
29
|
+
> 一般にAはBの特別な種類であるときは継承関係、AはBの性質であるときにはオブジェクトコンポジションを使うとよいとされている。 StudentというのはPersonの一種だろうか、それともPersonの性質にすぎないだろうか
|
|
30
|
+
|
|
31
|
+
AはBの特別な種類であるとき：A is a B.
|
|
32
|
+
AはBの性質であるとき：B has a A.
|
|
33
|
+
ですから、
|
|
34
|
+
StudentというのはPersonの一種だろうか→Student is a Person.
|
|
35
|
+
StudentというのはPersonの性質にすぎないだろうか→Person has a Student.
|
|
36
|
+
ですね。
|
|
37
|
+
|
|
38
|
+
直後に下記のように書かれてます。
|
|
39
|
+
> 学生でかつ社会人なんて言う人がいるケースを扱わねばならないとしたら、性質と捉えてオブジェクトコンポジションを使うべきだろうね。
|
|
40
|
+
|
|
41
|
+
つまり、Personが学生という性質、および、社会人という性質の両方を持つ可能性に言及し、コンポジションが良いと言ってます。
|
|
42
|
+
従って、実装する場合は、下記ですね。
|
|
43
|
+
```C++
|
|
44
|
+
class Person
|
|
45
|
+
{
|
|
46
|
+
Student student;
|
|
47
|
+
Worker worker;
|
|
48
|
+
};
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
しかし、例示されたプログラムでは下記のようになってます。
|
|
52
|
+
```Java
|
|
53
|
+
public class Student
|
|
54
|
+
{
|
|
55
|
+
private Person person;
|
|
56
|
+
}
|
|
57
|
+
```
|
|
58
|
+
このプログラムは「人という性質を持っている学生」とモデル化してます。逆です。「学生という性質を持っている人」ですよね。
|
|
59
|
+
つまり、コンポジションの主旨に沿わない実装を提示して、継承より適切と結論付けてます。（あっはっは）
|
|
60
|
+
|
|
61
|
+
##### 【Effective Java】項目１６：継承よりコンポジションを選ぶ
|
|
62
|
+
> 継承はカプセル化を破壊する。 そのため、サブクラスはスーパークラスの実装に依存することになり、スーパークラスの実装が変わった場合、意図せずサブクラスの挙動が変わる可能性がある。
|
|
63
|
+
|
|
64
|
+
依存先のクラスをA、それを使っているクラスをB、更にBを使っているクラスをCとします。
|
|
65
|
+
「継承の場合はAの仕様を直接Bが公開するのでAが変化した時Bを使っているCにも影響する」、しかし、「コンポジションなら、Aを仕様変更しても影響はBにとどまりCに影響しないことが可能」と言いたいのだと思います。
|
|
66
|
+
でも逆に、Cにも反映しなければ行けないような仕様変更をAに施す際にBを触らなくても良い場合があり、それが継承のメリットです。コポジションの時はBも触らないと行けません。
|
|
67
|
+
|
|
68
|
+
要は継承とコンポジョンで仕様変更時の影響範囲が異なります。将来の拡張可能正を考慮しつつ、適切な方を選ぶべきです。コンポジョンを選んだ方が影響範囲が狭いと決めつけていますが根拠レスですね。
|
|
69
|
+
|
|
70
|
+
また、下記としてプログラムが掲載されてます。
|
|
71
|
+
> サブクラスの危険性を示すため、HashSet を拡張した InstrumentedHashSet クラスを例にとる。
|
|
72
|
+
|
|
73
|
+
しかし、これは単なるバグです。InstrumentedHashSet<E>::addAll()は`addCount += c.size();`してはいけないのに、仮想関数の意味を理解しないままやってしまったバグです。
|
|
74
|
+
|
|
75
|
+
要するに、フールプルーフとして継承は使わない方が良いと言っていることになります。
|
|
76
|
+
確かに継承は単にメンバ変数として実装するより技術的に難易度高いので、素人は使うなって間違ってはいないですが、いくらなんでもそれは読者をバカにしすぎてないでしょうか？
|