回答編集履歴
1
コメント欄への回答を追記（コメ欄に書くと長くなるため）
test
CHANGED
|
@@ -45,3 +45,79 @@
|
|
|
45
45
|
|
|
46
46
|
|
|
47
47
|
けっきょく、オブジェクト指向も手段なので、目的に合わせて使いわけます。
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
|
|
55
|
+
> オブジェクト指向を駆使したものが
|
|
56
|
+
|
|
57
|
+
> 抽象度が高くなるのですか？（コメ欄）
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
|
|
61
|
+
プログラミングは書くより読む方が難しいので、修正コストが高いです。
|
|
62
|
+
|
|
63
|
+
とくに、大規模なプログラムを長い間少しずつ拡張するのは大変です。
|
|
64
|
+
|
|
65
|
+
|
|
66
|
+
|
|
67
|
+
変更コストを下げたい → 交換しやすくする →
|
|
68
|
+
|
|
69
|
+
（中心部の）抽象度を上げる → オブジェクト指向を使って設計する
|
|
70
|
+
|
|
71
|
+
|
|
72
|
+
|
|
73
|
+
ですから、結果的にはそうなるのですが、
|
|
74
|
+
|
|
75
|
+
上のような順番で根本には「変更コストを下げたい」という意識があります。
|
|
76
|
+
|
|
77
|
+
|
|
78
|
+
|
|
79
|
+
テトリスのブロックパターンが7つのまま固定なら、そんなに凝る必要はありません。
|
|
80
|
+
|
|
81
|
+
しかしもし、たとえば100パターンくらいに増やす予定なら、もっと抽象化します。
|
|
82
|
+
|
|
83
|
+
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
|
|
88
|
+
|
|
89
|
+
> オブジェクト指向はシンプルな設計を
|
|
90
|
+
|
|
91
|
+
> するのには向いていないのですかね？（コメ欄）
|
|
92
|
+
|
|
93
|
+
|
|
94
|
+
|
|
95
|
+
オブジェクト指向は、複雑な設計を「シンプル化」するのに向きます。
|
|
96
|
+
|
|
97
|
+
しかし、元からシンプルな設計対象に使うと、過剰設計になる場合があります。
|
|
98
|
+
|
|
99
|
+
|
|
100
|
+
|
|
101
|
+
たとえると、建物は木造よりコンクリの方が耐久力がありますが、田んぼにビルは建てませんし、
|
|
102
|
+
|
|
103
|
+
自転車より自動車の方が早いですが、歩いて5分なら車に乗る必要もありません。
|
|
104
|
+
|
|
105
|
+
|
|
106
|
+
|
|
107
|
+
同様にたとえば、ジャンケンゲームをオブジェクト指向で組むのは無意味に過剰です。
|
|
108
|
+
|
|
109
|
+
逆に、麻雀くらい複雑なルールだと効果がありそうです。テトリスは微妙なラインです。
|
|
110
|
+
|
|
111
|
+
|
|
112
|
+
|
|
113
|
+
ですから、オブジェクト指向などを駆使して高度な設計をするのは、
|
|
114
|
+
|
|
115
|
+
複雑性や不確定性に柔軟に対応するための、技術的な投資なのです。
|
|
116
|
+
|
|
117
|
+
|
|
118
|
+
|
|
119
|
+
オブジェクト指向が手続き指向の上位互換で、つねに勝るわけではありません。
|
|
120
|
+
|
|
121
|
+
プログラミングに「銀の弾丸」はなく、適材適所の使い分けがあるだけです。
|
|
122
|
+
|
|
123
|
+
|