回答編集履歴
3
誤字修正
answer
CHANGED
|
File without changes
|
2
誤字修正
answer
CHANGED
|
@@ -5,15 +5,14 @@
|
|
|
5
5
|
|
|
6
6
|
### KISS の原則
|
|
7
7
|
|
|
8
|
-
継承の欠点は、本来使わないはずの機能も使える様になってしまうことです。使わない機能が使える様になって何が問題なのでしょうか？継承は「KISS の原則」と相反するものなのかなと思っています。
|
|
8
|
+
継承の欠点は、本来使わないはずの機能も使える様になってしまうことです。使わない機能が使える様になって何が問題なのでしょうか？継承は「KISS の原則」と相反するものなのかなと思っています。
|
|
9
9
|
|
|
10
10
|
> [KISS の原則 (英: KISS principle)](https://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87) とは、「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）という内容の、1960年代の米国海軍において言われた、経験的な原理・原則[1]の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。
|
|
11
11
|
|
|
12
|
+
「KISS の原則」も原則というよりも、おそらく **経験則** かなと感じますが。そのため「じゃあ、なんで設計の単純性（簡潔性）は成功への鍵なのか？」、あるいは「KISS の原則は正しいのか？」と聞かれると答えに窮してしまうのですが...
|
|
12
13
|
|
|
14
|
+
|
|
13
15
|
### 依存性逆転の原則
|
|
14
|
-
|
|
15
|
-
じゃあ「なんで設計の単純性（簡潔性）は成功への鍵なのか？」、あるいは「KISS の原則は正しいのか？」と聞かれると答えに窮してしまうのですが...
|
|
16
|
-
|
|
17
16
|
「継承より合成」は、言い換えれば「使うメソッドだけ渡して、使わないメソッドは使わせない」とも言えるかなと思います。これと同じことが[「依存性逆転の原則」](https://ja.wikipedia.org/wiki/%E4%BE%9D%E5%AD%98%E6%80%A7%E9%80%86%E8%BB%A2%E3%81%AE%E5%8E%9F%E5%89%87) に見られます。
|
|
18
17
|
|
|
19
18
|
「依存性逆転の原則」も過度に単純化している可能性があるのですが、「関数あるいはメソッドの引数にはオブジェクトをそのまま渡さず、必要な属性だけ渡せ」ということだと思っています。
|
1
誤字修正
answer
CHANGED
|
@@ -40,4 +40,9 @@
|
|
|
40
40
|
|
|
41
41
|
**is-a 関係** をちゃんと満たす、あるいはコードに変更があったとしても **is-a 関係** 満たし続けてくれることは、なかなか無いのかなという中で Go, Rust といった言語では、継承という機能が切られてしまったのかなと思っています。
|
|
42
42
|
|
|
43
|
-
それでも今回のケースでは、継承の方がわかりやすいんじゃないのかなと思ったりもしています。
|
|
43
|
+
それでも今回のケースでは、継承の方がわかりやすいんじゃないのかなと思ったりもしています。
|
|
44
|
+
|
|
45
|
+
### まとめ
|
|
46
|
+
「継承より合成」あるいは「依存性逆転の原則」にしても、過度に単純化している可能性はあるのですが「必要なものだけ渡そう」ということなのかなと思います。
|
|
47
|
+
|
|
48
|
+
その背景としては「KISS の原則」がある様に感じます。原則というよりも経験則で、どっちか迷ったら「単純な方を」あるいは「必要なものだけ渡す方を」選択しておいた方が、無難なのかなと **思っています**。
|