回答編集履歴

9

文章の修正

2020/07/10 15:51

投稿

BluOxy
BluOxy

スコア2663

test CHANGED
@@ -67,3 +67,49 @@
67
67
  StringBuilder の全てのメンバーが static だった場合、**こういうときに困りませんか。**
68
68
 
69
69
  他のクラスに関して同様の違和感を感じた場合も、上記と同じように **もし〇〇がなかったらどう困るのか** という視点で考えると同様に疑問点が整理できると思います。
70
+
71
+
72
+
73
+ ----
74
+
75
+
76
+
77
+ > 疑問点は、インスタンス化しなくてもできるのに、なぜインスタンス化するのか。
78
+
79
+
80
+
81
+ 先に結論を書けば、[**オブジェクト指向プログラミング](https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91)ができないから**です。オブジェクト指向プログラミングができず、Javaという言語を利用して効率的にコードを組めないからです。
82
+
83
+
84
+
85
+ Javaは([クラスベース](https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%A9%E3%82%B9%E3%83%99%E3%83%BC%E3%82%B9)の)オブジェクト指向プログラミングという[プログラミングパラダイム](https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%83%91%E3%83%A9%E3%83%80%E3%82%A4%E3%83%A0#:~:text=%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%83%91%E3%83%A9%E3%83%80%E3%82%A4%E3%83%A0%20(%E8%8B%B1%3A%20programming%20paradigm,%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%91%E3%83%A9%E3%83%80%E3%82%A4%E3%83%A0%E3%81%A7%E3%81%82%E3%82%8B%E3%80%82)を有しており、当然言語仕様もそれに合わせて作られています。クラスベースなオブジェクト指向言語において、インスタンスの生成は効率的にコードを書くために必要な手段になります。
86
+
87
+
88
+
89
+ 一方、staticは[JavaのMathクラス](https://docs.oracle.com/javase/jp/10/docs/api/java/lang/Math.html)のような[副作用](https://ja.wikipedia.org/wiki/%E5%89%AF%E4%BD%9C%E7%94%A8_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0))のないメソッドを呼び出す場合においてはstaticである方が便利です。しかし、オブジェクト指向プログラミングを行う場合においては別で、staticなメソッドを呼び出す際はあらゆるオブジェクト指向の機能が使えません。例えば、継承・実装・ポリモーフィズム・カプセル化などが該当します。
90
+
91
+
92
+
93
+ オブジェクト指向を使うことのメリットは変更に対して柔軟になることですから、継承・実装・ポリモーフィズム・カプセル化を使わずにstaticで実装するとなると、めちゃくちゃなプログラムが出来上がるでしょう。
94
+
95
+
96
+
97
+ > 「副作用なんて悪いことばかりだし、必要ないじゃん」
98
+
99
+ > 「オブジェクト指向なんていらないじゃん」
100
+
101
+
102
+
103
+ と思われるかもしれません。(思わなかったらスルーしてください)
104
+
105
+ 確かにその考えもその通りです。
106
+
107
+
108
+
109
+ しかし、先述したようにJavaのプログラミングパラダイムがそのようになっていますから、Javaにおいてはオブジェクト指向を利用したコーディングをする方がstaticで対応するよりも効率的です。そうなるよう言語仕様が決まっているのです。
110
+
111
+
112
+
113
+ なので、もし kobe2018 さんが本当に「オブジェクト指向なんて抽象的で分かりづらい、全部staticで良いじゃん」と思われるようであれば、プログラミングパラダイムは1つだけではありませんから、色々な言語を触ってみると良いと思います。
114
+
115
+ (副作用があることが嫌なのであれば、[関数型言語](https://ja.wikipedia.org/wiki/%E9%96%A2%E6%95%B0%E5%9E%8B%E8%A8%80%E8%AA%9E)はいかがでしょう。私は興味ありますが、触ったことはありません)

8

文章の修正

2020/07/10 15:51

投稿

BluOxy
BluOxy

スコア2663

test CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
 
4
4
 
5
- 加えて、 **全てのメンバーに対して static をつけて作ったらどう困るか** という視点で考えるのも疑問点を整理する1つの手だと思います。試しに架空の StringBuilder を作り、全てのメンバーを static にしてみましょう。
5
+ 加えて、**全てのメンバーに対して static をつけて作ったらどう困るか** という視点で考えるのも疑問点を整理する1つの手だと思います。試しに架空の StringBuilder を作り、全てのメンバーを static にしてみましょう。
6
6
 
7
7
 
8
8
 

7

文章の修正

2020/07/04 18:27

投稿

BluOxy
BluOxy

スコア2663

test CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
 
4
4
 
5
- 加えて、 **全てのフィルド・メソッドに対して static をつけて作ったらどう困るか** という視点で考えるのも疑問点を整理する1つの手だと思います。試しに架空の StringBuilder を作り、全てのフィルド・メソッドを static にしてみましょう。
5
+ 加えて、 **全てのメンバーに対して static をつけて作ったらどう困るか** という視点で考えるのも疑問点を整理する1つの手だと思います。試しに架空の StringBuilder を作り、全てのメンバーを static にしてみましょう。
6
6
 
7
7
 
8
8
 
@@ -64,6 +64,6 @@
64
64
 
65
65
 
66
66
 
67
- StringBuilder の全てのフィルド・メソッドが static だった場合、**こういうときに困りませんか。**
67
+ StringBuilder の全てのメンバーが static だった場合、**こういうときに困りませんか。**
68
68
 
69
69
  他のクラスに関して同様の違和感を感じた場合も、上記と同じように **もし〇〇がなかったらどう困るのか** という視点で考えると同様に疑問点が整理できると思います。

6

文章の修正

2020/07/04 18:26

投稿

BluOxy
BluOxy

スコア2663

test CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
 
4
4
 
5
- 加えて、 **全てのメソッドに対して static をつけて作ったらどう困るか** という視点で考えるのも疑問点を整理する1つの手だと思います。試しに架空の StringBuilder を作り、メソッドを static にしてみましょう。
5
+ 加えて、 **全てのフィールド・メソッドに対して static をつけて作ったらどう困るか** という視点で考えるのも疑問点を整理する1つの手だと思います。試しに架空の StringBuilder を作り、全てのフィールド・メソッドを static にしてみましょう。
6
6
 
7
7
 
8
8
 
@@ -64,6 +64,6 @@
64
64
 
65
65
 
66
66
 
67
- StringBuilder が static だった場合、**こういうときに困りませんか。**
67
+ StringBuilder の全てのフィールド・メソッドが static だった場合、**こういうときに困りませんか。**
68
68
 
69
69
  他のクラスに関して同様の違和感を感じた場合も、上記と同じように **もし〇〇がなかったらどう困るのか** という視点で考えると同様に疑問点が整理できると思います。

5

コード修正

2020/07/04 18:25

投稿

BluOxy
BluOxy

スコア2663

test CHANGED
@@ -10,7 +10,7 @@
10
10
 
11
11
  public class StringBuilder{
12
12
 
13
- private static String value;
13
+ private static String value = "";
14
14
 
15
15
  public static void append(String s){
16
16
 

4

文章の修正

2020/07/04 18:24

投稿

BluOxy
BluOxy

スコア2663

test CHANGED
@@ -66,4 +66,4 @@
66
66
 
67
67
  StringBuilder が static だった場合、**こういうときに困りませんか。**
68
68
 
69
- 他のクラスに関して同様の違和感を感じた場合も、上記ような視点で考えると同様に疑問点が整理できると思います。
69
+ 他のクラスに関して同様の違和感を感じた場合も、上記と同じように **もし〇〇がかったらどう困るのか** という視点で考えると同様に疑問点が整理できると思います。

3

文章の修正

2020/07/04 18:23

投稿

BluOxy
BluOxy

スコア2663

test CHANGED
@@ -66,10 +66,4 @@
66
66
 
67
67
  StringBuilder が static だった場合、**こういうときに困りませんか。**
68
68
 
69
-
70
-
71
- > 実際に存在しないものに関してはどうしても違和感があります
72
-
73
-
74
-
75
- 他の現実世界に存在しないクラスに関して違和感を感じた場合、上記のように想定したら解決しせんか
69
+ 他のクラスに関して同様の違和感を感じた場合、上記のような視点で考えると同様疑問点が整理できると思い

2

文章の修正

2020/07/04 18:22

投稿

BluOxy
BluOxy

スコア2663

test CHANGED
@@ -1,12 +1,8 @@
1
- インスタンスやstaticの使い道は momon-ga さんの回答で既に述べられているので省略します。
1
+ インスタンス static の使い道は momon-ga さんの回答で既に述べられているので省略します。
2
2
 
3
3
 
4
4
 
5
- 加えて、さらに全てのメソッドに対して static をつけて作ったらどう困るかという視点で考えてみるのも手だと思います。
5
+ 加えて、 **全てのメソッドに対して static をつけて作ったらどう困るか** という視点で考えるのも疑問点を整理する1つの手だと思います。試しに架空の StringBuilder を作り、メソッドを static にしてみましょう。
6
-
7
-
8
-
9
- 試しに架空の StringBuilder を作り、メソッドを static にしてみましょう。
10
6
 
11
7
 
12
8
 

1

文章の修正

2020/07/04 18:20

投稿

BluOxy
BluOxy

スコア2663

test CHANGED
@@ -1,4 +1,8 @@
1
+ インスタンスやstaticの使い道は momon-ga さんの回答で既に述べられているので省略します。
2
+
3
+
4
+
1
- クラスやメソッドに対して static をつけて作ったらどう困るか挑戦したらインスタンスが必要な理由が理解しれせん
5
+ 加えて、さらに全のメソッドに対して static をつけて作ったらどう困るかという視点考えてみ手だと思い
2
6
 
3
7
 
4
8