回答編集履歴
12
なんとなく変な気がしたので抽象化のメリットを少し考え直した。
test
CHANGED
|
@@ -246,11 +246,11 @@
|
|
|
246
246
|
|
|
247
247
|
ですが、抽象化ができていないアプリケーションはできているアプリケーションよりも
|
|
248
248
|
|
|
249
|
-
-
|
|
249
|
+
- 機能変更の際の修正範囲が大きいため、保守が大変になる
|
|
250
|
-
|
|
251
|
-
|
|
250
|
+
|
|
252
|
-
|
|
253
|
-
-
|
|
251
|
+
- 特化(具体化)したクラスしかないため、クラスを別のアプリケーションで再利用しづらい
|
|
252
|
+
|
|
253
|
+
- ~~コード量が増えるため、プログラム全体の可読性が悪くなる~~ これはどちらかというと具象化ではなく共通化できていないアプリケーションの話でした
|
|
254
254
|
|
|
255
255
|
|
|
256
256
|
|
11
whyがないので入れた
test
CHANGED
|
@@ -246,11 +246,11 @@
|
|
|
246
246
|
|
|
247
247
|
ですが、抽象化ができていないアプリケーションはできているアプリケーションよりも
|
|
248
248
|
|
|
249
|
-
- 保守が大変
|
|
249
|
+
- 改修の際に影響箇所が特定し辛くなるため、保守が大変
|
|
250
|
-
|
|
250
|
+
|
|
251
|
-
- コード量が増えるため可読性
|
|
251
|
+
- コード量が増えるため、プログラム全体の可読性が悪くなる
|
|
252
|
-
|
|
252
|
+
|
|
253
|
-
- クラスを再利用しづらい
|
|
253
|
+
- 各クラスが特化(具体化)するため、クラスを再利用しづらい
|
|
254
254
|
|
|
255
255
|
|
|
256
256
|
|
10
戻り値が配列ではなかったので修正…
test
CHANGED
|
@@ -152,7 +152,7 @@
|
|
|
152
152
|
|
|
153
153
|
public byte[] CoarseAdjustRead (int id, int bank) {
|
|
154
154
|
|
|
155
|
-
return
|
|
155
|
+
return new bytes[1];
|
|
156
156
|
|
|
157
157
|
}
|
|
158
158
|
|
9
文章の修正
test
CHANGED
|
@@ -26,7 +26,7 @@
|
|
|
26
26
|
|
|
27
27
|
|
|
28
28
|
|
|
29
|
-
|
|
29
|
+
文章で`can-do`の表現ができるのなら、当然コードでも同じことが表現できるようになります。
|
|
30
30
|
|
|
31
31
|
```C#
|
|
32
32
|
|
|
@@ -186,7 +186,7 @@
|
|
|
186
186
|
|
|
187
187
|
|
|
188
188
|
|
|
189
|
-
共通の「振る舞い」が抽出できるのなら、内部の動きに差異があってもインタフェースは利用できると思います。
|
|
189
|
+
共通の「振る舞い」が抽出できるのなら、仮に内部の動きに差異があったとしてもインタフェースは利用できると思います。
|
|
190
190
|
|
|
191
191
|
|
|
192
192
|
|
|
@@ -258,4 +258,4 @@
|
|
|
258
258
|
|
|
259
259
|
|
|
260
260
|
|
|
261
|
-
なので、もしポリモーフィズムという機能を利用することで、そのアプリケーションの開発が効率的にできる見込みがふんわりとでもあるのなら、**継承
|
|
261
|
+
なので、もしポリモーフィズムという機能を利用することで、そのアプリケーションの開発が効率的にできる見込みがふんわりとでもあるのなら、**継承やインタフェースなどを使った適切なクラス設計ができないか時間をかけてでも検討するべき**と思います。
|
8
ちょっと文章をたしました
test
CHANGED
|
File without changes
|
7
ちょっと文章をたしました
test
CHANGED
|
@@ -26,6 +26,8 @@
|
|
|
26
26
|
|
|
27
27
|
|
|
28
28
|
|
|
29
|
+
その場合、コードでも同じことが表現できるようになります。
|
|
30
|
+
|
|
29
31
|
```C#
|
|
30
32
|
|
|
31
33
|
interface ICoarseAdjustReadable {
|
6
マークダウンの修正
test
CHANGED
|
@@ -250,6 +250,8 @@
|
|
|
250
250
|
|
|
251
251
|
- クラスを再利用しづらい
|
|
252
252
|
|
|
253
|
+
|
|
254
|
+
|
|
253
255
|
など、あとで**技術的な負債が降りかかってくる**と思います。
|
|
254
256
|
|
|
255
257
|
|
5
文章の修正
test
CHANGED
|
@@ -248,9 +248,7 @@
|
|
|
248
248
|
|
|
249
249
|
- コード量が増えるため可読性も悪い
|
|
250
250
|
|
|
251
|
-
- クラス
|
|
251
|
+
- クラスを再利用しづらい
|
|
252
|
-
|
|
253
|
-
|
|
254
252
|
|
|
255
253
|
など、あとで**技術的な負債が降りかかってくる**と思います。
|
|
256
254
|
|
4
文章の修正
test
CHANGED
|
@@ -234,7 +234,7 @@
|
|
|
234
234
|
|
|
235
235
|
|
|
236
236
|
|
|
237
|
-
※
|
|
237
|
+
※上記は抽象化についての説明に利用しただけです。実際は自作をしない限りCSVは`CsvHelper`を使って、JSONは`Json.NET`を使うべきと思います
|
|
238
238
|
|
|
239
239
|
|
|
240
240
|
|
3
byteは予約語だったのを忘れていたのでなおしました
test
CHANGED
|
@@ -168,9 +168,9 @@
|
|
|
168
168
|
|
|
169
169
|
var bytes = readable.CoarseAdjustRead(1,2);
|
|
170
170
|
|
|
171
|
-
foreach(var b
|
|
171
|
+
foreach(var b in bytes){
|
|
172
|
-
|
|
172
|
+
|
|
173
|
-
Console.WriteLine(b
|
|
173
|
+
Console.WriteLine(b);
|
|
174
174
|
|
|
175
175
|
}
|
|
176
176
|
|
2
文章の修正、コード修正
test
CHANGED
|
@@ -166,7 +166,13 @@
|
|
|
166
166
|
|
|
167
167
|
public void Sample(ICoarseAdjustReadable readable){
|
|
168
168
|
|
|
169
|
-
readable.CoarseAdjustRead(1,2);
|
|
169
|
+
var bytes = readable.CoarseAdjustRead(1,2);
|
|
170
|
+
|
|
171
|
+
foreach(var byte in bytes){
|
|
172
|
+
|
|
173
|
+
Console.WriteLine(byte);
|
|
174
|
+
|
|
175
|
+
}
|
|
170
176
|
|
|
171
177
|
}
|
|
172
178
|
|
|
@@ -250,4 +256,4 @@
|
|
|
250
256
|
|
|
251
257
|
|
|
252
258
|
|
|
253
|
-
なので、もしポリモーフィズムという機能を利用することで、そのアプリケーションの開発が効率的にできる見込みがふんわりとでもあ
|
|
259
|
+
なので、もしポリモーフィズムという機能を利用することで、そのアプリケーションの開発が効率的にできる見込みがふんわりとでもあるのなら、**継承関係やインタフェースなどを適切に使ってクラス設計ができないか時間をかけてでも検討するべき**と思います。
|
1
文章の修正
test
CHANGED
|
@@ -234,7 +234,19 @@
|
|
|
234
234
|
|
|
235
235
|
#最後に
|
|
236
236
|
|
|
237
|
-
`public Rs232cController serialController;`の型を`TB2448DUTY24`にすることでも勿論その場での問題は解決されるかもしれません。
|
|
237
|
+
`public Rs232cController serialController;`の型を`TB2448DUTY24`にすることでも勿論その場での問題は解決されるかもしれません。
|
|
238
|
+
|
|
239
|
+
ですが、抽象化ができていないアプリケーションはできているアプリケーションよりも
|
|
240
|
+
|
|
241
|
+
- 保守が大変
|
|
242
|
+
|
|
243
|
+
- コード量が増えるため可読性も悪い
|
|
244
|
+
|
|
245
|
+
- クラスの再利用が中々できない(明確な根拠はありませんが、そうなると思います)
|
|
246
|
+
|
|
247
|
+
|
|
248
|
+
|
|
249
|
+
など、あとで**技術的な負債が降りかかってくる**と思います。
|
|
238
250
|
|
|
239
251
|
|
|
240
252
|
|