teratail
回答率
85.48%
質問するログイン新規登録
トップオブジェクトに関する質問インターフェースって何のメリットがあるんですか？

編集履歴

回答編集履歴

4

冗長な部分を修正

2019/02/16 18:39

投稿

xenbeat
xenbeat

スコア4258

test CHANGED
@@ -1,8 +1,10 @@
1
+ 既に回答が出揃ってる感ありますが、少しでもお役に立てればと思ったので回答させていただきます。
2
+
1
- すでに回答が出揃ってる感ありますが、僕も初学の際に同じような疑問を持っていたので、僕なりにわかりやすくお伝えできて、少しでもお役に立てればと思ったので回答させていただきます。
3
+ 僕も初学の際に同じような疑問を持っていたので、僕なりにわかりやすくお伝えできればと思います。
2
4
 
3
5
 
4
6
 
5
- #####前提
7
+ ##### 前提
6
8
 
7
9
 
8
10
 
@@ -16,41 +18,23 @@
16
18
 
17
19
 
18
20
 
19
- 故に、上記ではないアプリケーションの開発を対象として説明させていただきます。（ほとんどこのケースですが・・・）
21
+ 故に、上記に当てはまらないアプリケーション開発をイメージして説明させていただきます。
22
+
23
+ （ほとんどこのケースですが・・・）
20
24
 
21
25
 
22
26
 
23
27
 
24
28
 
25
- #####説明
29
+ ##### 説明
26
30
 
27
31
  > 何のメリットがあるんですか？
28
32
 
29
33
 
30
34
 
31
- 【Who】
35
+ インターフェースの実装が増えても利用者はそれを意識せず形式的に利用できるというメリットがあります。
32
36
 
33
- 主にインターフェースのメソッドを利用する人にメリット
34
-
35
-
36
-
37
- 【When】
38
-
39
- インターフェースの実装が増えた時にメリット
40
-
41
-
42
-
43
- 【What】
44
-
45
- インターフェースの実装が増えても利用者はそれを意識せず形式的に利用できるというメリット
46
-
47
-
48
-
49
-
50
-
51
- 【Why/How】
52
-
53
- 例を踏まえて後述
37
+ 詳細は、例を踏まえて後述します。
54
38
 
55
39
 
56
40
 
@@ -60,9 +44,9 @@
60
44
 
61
45
 
62
46
 
63
- 長期的な目線で見ると短縮されることがあります。
47
+ 上記のメリットがあるので、長期的な目線で見ると短縮されることがあります。
64
48
 
65
- 一発ものでは、ファイルを余計に作成することになるので逆に開発は長くなります。
49
+ ただし、一度作って終わるものはファイルを余計に作成するだけなので逆に開発が延びます。
66
50
 
67
51
 
68
52
 
@@ -70,7 +54,7 @@
70
54
 
71
55
 
72
56
 
73
- 将来的に起こりうる変更を予測して、最初からきちんと完璧に設計できるのであれば、それに越したことはありません
57
+ 将来的に起こりうる変更を予測して、おっしゃるように「最初からきちんと完璧に設計」できるのであれば、それに越したことはありません。
74
58
 
75
59
 
76
60
 
@@ -94,43 +78,49 @@
94
78
 
95
79
 
96
80
 
97
- では、その考え方が、具体的に実務でどのように活かされているのかを、簡単な例にはなりますが記載させていただきます。
81
+ では具体的に、その考え方がどのように実装に活かされるのかを、簡単な例になりますが見ていきましょう。
98
82
 
99
- ちなみに以降は、レイヤ化アーキテクチャ（MVC等）の知識が前提になります。
83
+ TODO管理のアプリケーションをチーム（複数人）で開発する場面を想像してみてください。
100
84
 
101
85
 
102
86
 
87
+ 0. まず、TODOのデータを保存する場所を考える必要がありますよね。
88
+
89
+ 最初は、開発スピード等を重視して、この保存先にローカルのファイルを選んだとしましょう。
90
+
103
- それでは、簡単なTODOを管理するアプリケーションを開発する場面を想像してください。（TODOだとCRUDが基本ですが、ここではReadにフォーカスします）
91
+ 0. 次に、少なくともリクエストをコントロールする「クラスA」と、ローカルのファイルに対してTODOデータをCRUDする「クラスB」を実装すると思います。
92
+
93
+ ※ここでは「クラスA」と「クラスB」との間にインターフェース（契約）を設けないでアプリケーションを作り上げたとします。
94
+
95
+ 0. リリース後、ユーザーが順調に増え、アプリケーションがまともに動かなくなってきました。
96
+
97
+ 0. スケーラブルな構成への変更を余儀なくされ、データの保存先をローカルのファイルから、クラウドのRDBMSへ移行することを決めます。
98
+
99
+ 0. そして、誰かがRDBMSに対してTODOデータをCRUDする「クラスC」を実装しようとします。
104
100
 
105
101
 
106
102
 
107
- 0. まずTODOのデータを保存する場所を考える必要がありますよね？最初はコストを抑えて、この保存先にはオープンソースのRDBMSを選んだとしましょう。
103
+ ここからが悲劇の始まりです。
108
104
 
109
- 0. そうすると、少なくとも、リクエストをコントロールする「クラスA」の作成と、RDBMSに対してTODOデータCRUDするメソッドを持った「クラスB」を作成すると思います。
105
+ 過去に誰かが実装した「クラスA」は「クラスB」からデータをもらう前提で実装されています。
110
106
 
111
- 0. そのまま、「クラスA」と「クラスB」との間にインターフェース（契約）を設けないでアプリケーションを作り上げたとします。
107
+ 今回の変更で「クラスA」は「クラスB」ではなく「クラスC」からデータをもらうことになるので「クラスC」の実装・テストに加え「クラスC」の実装を知った上で「クラスA」の修正・テストも必要になります。
112
108
 
113
- 0. しかし１年後、オープンソースのRDBMSに深刻な脆弱性が見つかり、それを使い続けていくことが難しくなったとします。
114
-
115
- 0. そこで、高速でセキュアな無料で使えるクラウドのデータストレージサービス（以下「クラウド」）があったとして、それに移行することを決めたとします。
116
-
117
- 0. そうすると、クラウドに対してTODOデータをCRUDする「クラスC」を作成することになると思います。
109
+ せっかく責務を分離してクラスを分けていたのに、結局クラスAへの影響も大きそうですね。。。
118
-
119
- 0. そのため、「クラスA」は、「クラスB」と同様に「クラスC」がデータをどこから取ってきて、どういう型で返却してくるかを知る必要があります。
120
110
 
121
111
 
122
112
 
113
+ もし、最初から「クラスA」と「クラスB（TODOデータをCRUDするクラス）」との間にインターフェース（契約）があれば、今回も「クラスC」がそのインターフェースを実装することによって戻り値の型は保証されるので「クラスA」は「クラスC」の実装を知る必要がありません。
114
+
115
+ そして多くの場合「クラスA」にほとんど影響はありません。
116
+
117
+ また、この先NoSQLに対してCRUDを行う「クラスD」、新型のDBに対してCRUDを行う「クラスE」・・・が現れても「クラスA」と「TODOデータをCRUDするクラス」との間にインターフェース（契約）があるかぎり「クラスA」はそのクラスの実装を全く意識する必要はありません。
118
+
123
- つまり、「クラスC」の戻り値の型が保証されていないので、「クラスC」のテストに加え、「クラスA」のテストも必要になりますし、場合によっては、「クラスA」を修正することになります。
119
+ 「クラスA」は「クラスB〜E・・・」がどんな実装をしてどこからデータを取ってこようが、それらのクラスが契約通りに実装してくれれば「クラスA」に変更が加わることは原則ありません。
124
120
 
125
121
 
126
122
 
127
- もし「クラスA」と「データをCRUDするクラス」との間に、最初から共通のインターフェース（契約）があれば、データの取得元は変わっても戻り値の型は保証されるので、「クラスA」は「クラスC」の実装を知る必要がありませんし、この先、ファイルに対してCRUDを行う「クラスD」、NoSQLに対してCRUDを行う「クラスE」、メモリキャッシュに対してCRUDを行う「クラスF」・・・が現れても、「クラスA」との間にインターフェース（契約）がある以上、「クラスA」は全く実体を意識する必要はありません。また、多くの場合「クラスA」に影響はありません。
128
-
129
- 上位レイヤーの「クラスA」は、下位レイヤーの「クラスB・・D」がどんな実装をしてどこからデータを取ってこようが、同じ型の値を契約どおりに返してくれれば、「クラスA」に変更が加わることは原則ありません。
130
-
131
-
132
-
133
- 実用例の一部を紹介してきましたが、前述の通り、役割ごとにカテゴライズされた**各レイヤー間にインターフェース（契約）を設ける**ことによって、**各レイヤー間を疎結合にし**（依存度を低くし）、**変更に強いアプリケーション作ることができる**
123
+ 以上、簡単な例でしたが前述の通り、役割ごとにカテゴライズされた**各レイヤー間にインターフェース（契約）を設ける**ことによって、**各レイヤー間を疎結合にし**（依存度を低くし）、**変更に強いアプリケーション作ることができる**
134
124
 
135
125
  これがインターフェースを利用する最大のメリットと言っても過言ではないと思います。
136
126
 

3

edit

2019/02/16 18:39

投稿

xenbeat
xenbeat

スコア4258

test CHANGED
@@ -80,7 +80,7 @@
80
80
 
81
81
 
82
82
 
83
- 一般的に、インターフェースとは契約と言われています。
83
+ 一般的に、インターフェースとは「契約」と言われることが多いです。
84
84
 
85
85
  日常生活で身近な契約って何だろて考えたときに、電力会社との契約とかがわかりやすいかなと思います。
86
86
 
@@ -141,5 +141,3 @@
141
141
  インターフェースのメリットを最大限に活かす仕組みとしてDependency Injection(依存性の注入)というデザインパターンがあります。
142
142
 
143
143
  少々複雑な上、質問に対する回答にはならないのでここでは触れませんが、インターフェースを理解された次のステップとして、知っておくと良いと思います。
144
-
145
-

2

補足

2017/03/25 23:37

投稿

xenbeat
xenbeat

スコア4258

test CHANGED
@@ -96,7 +96,7 @@
96
96
 
97
97
  では、その考え方が、具体的に実務でどのように活かされているのかを、簡単な例にはなりますが記載させていただきます。
98
98
 
99
- ちなみに以降は、レイヤ化アーキテクチャ（MVC等）の知識が前提になります。DIの知識なんかもあるとさらに理解が深まると思います。
99
+ ちなみに以降は、レイヤ化アーキテクチャ（MVC等）の知識が前提になります。
100
100
 
101
101
 
102
102
 
@@ -114,9 +114,9 @@
114
114
 
115
115
  0. そこで、高速でセキュアな無料で使えるクラウドのデータストレージサービス（以下「クラウド」）があったとして、それに移行することを決めたとします。
116
116
 
117
- 0. そうすると、クラウドに対してTODOデータをCRUDする「クラスC」を「クラスB」と同様に「クラスA」とのインターフェース（契約）なしで作成することになると思います。
117
+ 0. そうすると、クラウドに対してTODOデータをCRUDする「クラスC」を作成することになると思います。
118
118
 
119
- 0. そのため、「クラスA」は「クラスC」がデータをどこから取ってきて、どういう型で返却してくるかを知る必要があります。
119
+ 0. そのため、「クラスA」は、「クラスB」と同様に「クラスC」がデータをどこから取ってきて、どういう型で返却してくるかを知る必要があります。
120
120
 
121
121
 
122
122
 
@@ -126,8 +126,20 @@
126
126
 
127
127
  もし「クラスA」と「データをCRUDするクラス」との間に、最初から共通のインターフェース（契約）があれば、データの取得元は変わっても戻り値の型は保証されるので、「クラスA」は「クラスC」の実装を知る必要がありませんし、この先、ファイルに対してCRUDを行う「クラスD」、NoSQLに対してCRUDを行う「クラスE」、メモリキャッシュに対してCRUDを行う「クラスF」・・・が現れても、「クラスA」との間にインターフェース（契約）がある以上、「クラスA」は全く実体を意識する必要はありません。また、多くの場合「クラスA」に影響はありません。
128
128
 
129
+ 上位レイヤーの「クラスA」は、下位レイヤーの「クラスB・・D」がどんな実装をしてどこからデータを取ってこようが、同じ型の値を契約どおりに返してくれれば、「クラスA」に変更が加わることは原則ありません。
129
130
 
130
131
 
131
- 実用例の一部を紹介しましたが、前述の通り、役割ごとにカテゴライズされた**各レイヤー間にインターフェース（契約）を設ける**ことによって、**変更に強いアプリケーション作ることができる**
132
132
 
133
+ 実用例の一部を紹介してきましたが、前述の通り、役割ごとにカテゴライズされた**各レイヤー間にインターフェース（契約）を設ける**ことによって、**各レイヤー間を疎結合にし**（依存度を低くし）、**変更に強いアプリケーション作ることができる**
134
+
133
- これがインターフェースを利用する最大のメリットと言っても過言ではないでしょう。
135
+ これがインターフェースを利用する最大のメリットと言っても過言ではないと思います。
136
+
137
+
138
+
139
+ #####補足
140
+
141
+ インターフェースのメリットを最大限に活かす仕組みとしてDependency Injection(依存性の注入)というデザインパターンがあります。
142
+
143
+ 少々複雑な上、質問に対する回答にはならないのでここでは触れませんが、インターフェースを理解された次のステップとして、知っておくと良いと思います。
144
+
145
+

1

edit

2017/03/25 22:59

投稿

xenbeat
xenbeat

スコア4258

test CHANGED
@@ -60,7 +60,7 @@
60
60
 
61
61
 
62
62
 
63
- 長期的な目線で見ると短縮されます。
63
+ 長期的な目線で見ると短縮されることがあります。
64
64
 
65
65
  一発ものでは、ファイルを余計に作成することになるので逆に開発は長くなります。
66
66
 
@@ -94,7 +94,7 @@
94
94
 
95
95
 
96
96
 
97
- では、その考え方が、具体的に実務でどのように活かされているのかを、極端な例にはなりますが記載させていただきますね。
97
+ では、その考え方が、具体的に実務でどのように活かされているのかを、簡単な例にはなりますが記載させていただきます。
98
98
 
99
99
  ちなみに以降は、レイヤ化アーキテクチャ（MVC等）の知識が前提になります。DIの知識なんかもあるとさらに理解が深まると思います。
100
100
 
@@ -128,6 +128,6 @@
128
128
 
129
129
 
130
130
 
131
- 実用例の１部を紹介しましたが、前述の通り、役割ごとにカテゴライズされた**各レイヤー間にインターフェース（契約）を設ける**ことによって、**変更に強いアプリケーション作ることができる**
131
+ 実用例の一部を紹介しましたが、前述の通り、役割ごとにカテゴライズされた**各レイヤー間にインターフェース（契約）を設ける**ことによって、**変更に強いアプリケーション作ることができる**
132
132
 
133
133
  これがインターフェースを利用する最大のメリットと言っても過言ではないでしょう。