回答編集履歴
2
途中の説明を更新
test
CHANGED
|
@@ -120,7 +120,9 @@
|
|
|
120
120
|
|
|
121
121
|
言語がインタフェースを持っていて、すべての**複数行の文字列を内部に格納するGUI**がMultiLineというインタフェースの実装になっていると想像してください。
|
|
122
122
|
|
|
123
|
-
|
|
123
|
+
インタフェースMultiLineには、`len`、`get`、`add`、`clear`などが定義されるはずです。
|
|
124
|
+
|
|
125
|
+
そうであれば、
|
|
124
126
|
|
|
125
127
|
```
|
|
126
128
|
|
|
@@ -146,25 +148,33 @@
|
|
|
146
148
|
|
|
147
149
|
|
|
148
150
|
|
|
149
|
-
ListBox`a`からListBox`b`にコピーしたいなら`copyMultiLine(a, b)`
|
|
151
|
+
ListBox`a`からListBox`b`にコピーしたいなら`copyMultiLine(a, b)`と呼べばいいし、
|
|
150
|
-
|
|
152
|
+
|
|
151
|
-
TextEdit`c`からListBox`d`にコピーしたいなら`copyMultiLine(c, d)`
|
|
153
|
+
TextEdit`c`からListBox`d`にコピーしたいなら`copyMultiLine(c, d)`と呼べばいいわけです。
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
154
|
+
|
|
156
|
-
|
|
157
|
-
そして、複数行の文字列を内部に格納するGUIコンポーネントは、そのインタフェースを実装すればいい。
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
そうなっていれば、あるインタフェースを持つ**もの**は、そこに定義してある機能を間違いなく**使える**と保証されるのです。
|
|
162
|
-
|
|
163
|
-
copyMultiLineのように、その機能だけに着目したプログラムが、書けるようになります。
|
|
164
|
-
|
|
165
|
-
copyLinesTextEditとcopyLinesListBox
|
|
155
|
+
copyLinesTextEditとcopyLinesListBoxが別になっている必要はないのです。
|
|
156
|
+
|
|
157
|
+
|
|
158
|
+
|
|
166
|
-
|
|
159
|
+
インタフェース（やクラス継承）の何が便利なのかわからない、という人の多くは、このような多態を利用した処理の書き方を知らないか、慣れていないように見受けられます。
|
|
160
|
+
|
|
167
|
-
|
|
161
|
+
TextEditやListBoxのような**具象**を引数に受け取る手続きは想像するのが容易です。しかしインタフェースのような**抽象**を引数に受け取る手続きが書ける、という想像がしにくいのでしょう。
|
|
162
|
+
|
|
163
|
+
|
|
164
|
+
|
|
165
|
+
抽象を引数に受け取る手続きには、それを具象化したものなら**なんでも**渡せます。
|
|
166
|
+
|
|
167
|
+
copyMultiLineにListBoxもTextEditもどちらも渡せるように。
|
|
168
|
+
|
|
169
|
+
インタフェースMultiLineの具象であるなら、インタフェースMultiLineで定義されている要素は**すべて実装されている**という保証があるからです。
|
|
170
|
+
|
|
171
|
+
|
|
172
|
+
|
|
173
|
+
インタフェースMultiLineを受け取るような手続きの中では、インタフェースMultiLineで定義されている要素だけしか使えません。しかしインタフェースMultiLineで定義されている要素だけで**意味がある一連の手続き**が書けていますよね。
|
|
174
|
+
|
|
175
|
+
|
|
176
|
+
|
|
177
|
+
そうできるようにインタフェースは定義されるべきです。
|
|
168
178
|
|
|
169
179
|
|
|
170
180
|
|
|
@@ -198,7 +208,7 @@
|
|
|
198
208
|
|
|
199
209
|
同じ手続きなら、違う名前をつけるのはよくないです。
|
|
200
210
|
|
|
201
|
-
（逆から言うと違う名前の方が相応しいなら、たまたま似ているだけの「別の概念」
|
|
211
|
+
（逆から言うと違う名前の方が相応しいなら、たまたま似ているだけの「別の概念」だと分析するべきです）
|
|
202
212
|
|
|
203
213
|
それはつまり、言語にインタフェースが存在しようがしまいが、ルールはある方がいいってことです。
|
|
204
214
|
|
1
「ルールを強制させる」ことについての追記
test
CHANGED
|
@@ -114,7 +114,7 @@
|
|
|
114
114
|
|
|
115
115
|
|
|
116
116
|
|
|
117
|
-
そこでインタフェースの出番です。（正確には
|
|
117
|
+
そこでインタフェースの出番です。（正確には多態性の出番とするべきでしょうか。インタフェースは多態性を実現するひとつに手段に過ぎません）
|
|
118
118
|
|
|
119
119
|
|
|
120
120
|
|
|
@@ -152,16 +152,10 @@
|
|
|
152
152
|
|
|
153
153
|
|
|
154
154
|
|
|
155
|
-
なぜこれで済むのか?
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
155
|
複数行の文字列を内部に格納するGUIは、このような**操作を持っているはずだ**と想定できるなら、それをインタフェースとして定義します。
|
|
160
156
|
|
|
161
157
|
そして、複数行の文字列を内部に格納するGUIコンポーネントは、そのインタフェースを実装すればいい。
|
|
162
158
|
|
|
163
|
-
それが「ルールを強制させる」の意味です。
|
|
164
|
-
|
|
165
159
|
|
|
166
160
|
|
|
167
161
|
そうなっていれば、あるインタフェースを持つ**もの**は、そこに定義してある機能を間違いなく**使える**と保証されるのです。
|
|
@@ -178,8 +172,38 @@
|
|
|
178
172
|
|
|
179
173
|
|
|
180
174
|
|
|
181
|
-
順番に気をつけてください。
|
|
175
|
+
考える順番に気をつけてください。
|
|
182
176
|
|
|
183
177
|
「ある概念を内包する部品」を設計する時、それらは「このような操作を持っているはずだ」という発想が先です。
|
|
184
178
|
|
|
185
179
|
それをルールとして定義するものがインタフェースです。
|
|
180
|
+
|
|
181
|
+
|
|
182
|
+
|
|
183
|
+
GUIを構築するためのプログラムを考えます。
|
|
184
|
+
|
|
185
|
+
リストボックスとか、プルダウンリスト、コンボボックスを操作する手続きを考えていると、これらは（文字列の取得とか追加とか件数の取得とか初期化とかの）同じような操作が必要なことに気づきます。
|
|
186
|
+
|
|
187
|
+
それはなぜかというと「順序がある複数の文字列を内部に持つ」という構造が同じだからです。
|
|
188
|
+
|
|
189
|
+
そう考えると用途は違っても、テキストボックスも同様な構造を持つことがわかります。
|
|
190
|
+
|
|
191
|
+
|
|
192
|
+
|
|
193
|
+
たとえ言語にインタフェースが**存在しなかった**としても、リストボックスは`get(int)`で、プルダウンリストは`item(int)`で、テキストエディットは`line(int)`で文字列を取得するようなら、とても変じゃありませんか?
|
|
194
|
+
|
|
195
|
+
|
|
196
|
+
|
|
197
|
+
同じ概念を内包するコンポーネントなら、違う手続きで操作するのはよくないです。
|
|
198
|
+
|
|
199
|
+
同じ手続きなら、違う名前をつけるのはよくないです。
|
|
200
|
+
|
|
201
|
+
（逆から言うと違う名前の方が相応しいなら、たまたま似ているだけの「別の概念」を取り扱っていると分析するべきです）
|
|
202
|
+
|
|
203
|
+
それはつまり、言語にインタフェースが存在しようがしまいが、ルールはある方がいいってことです。
|
|
204
|
+
|
|
205
|
+
|
|
206
|
+
|
|
207
|
+
言語要素としてのインタフェースは、そういったルールを宣言する、あるいは明確にするのに役立ちます。また、ルールが遵守されていることを保証してくれます。
|
|
208
|
+
|
|
209
|
+
それが「ルールを強制させる」の意味もしくはメリットです。
|