回答編集履歴

3

冗長な記述を削除

2018/01/25 20:15

投稿

KSwordOfHaste
KSwordOfHaste

スコア18394

test CHANGED
@@ -20,17 +20,13 @@
20
20
 
21
21
 
22
22
 
23
- 場合によってはクラスのインスタンスをスレッドスコープにおくように考えればstaticであることは逆に「損」になり普通にインスタンスフィールドであることの方が自然になると思います。staticよりインスタンスフィールドやクロージャーのようなものの方がより柔軟であると思います。
24
-
25
-
26
-
27
23
  > それともjavaだと以外と気にせず下のように毎回実行しちゃったり
28
24
 
29
25
  するんでしょうか?なんかすごく無駄な処理をしてる感じで気持ち悪いのですが。
30
26
 
31
27
 
32
28
 
33
- staticかどうかと関係のない議論だと思います。変化をきっかけになにかを起動するというイベントドリブンな方法論を用いて解決を図るのがよいと思いますがそれとstaticな変数が使えるかどうかは別の問題のような気がします。
29
+ 変化をきっかけになにかを起動するというイベントドリブンな方法論を用いて解決を図るのがよいと思いますがそれとstaticな変数が使えるかどうかは別の問題のような気がします。
34
30
 
35
31
 
36
32
 

2

誤記訂正

2018/01/25 20:15

投稿

KSwordOfHaste
KSwordOfHaste

スコア18394

test CHANGED
@@ -34,4 +34,4 @@
34
34
 
35
35
 
36
36
 
37
- 抽象的なコメントでスミマセン
37
+ 抽象的なコメントでスミマセン。

1

誤記訂正

2018/01/25 09:02

投稿

KSwordOfHaste
KSwordOfHaste

スコア18394

test CHANGED
@@ -12,7 +12,7 @@
12
12
 
13
13
 
14
14
 
15
- Javaにはクラスというスコープがあります。クラススコープ内のstaticな情報として考えるのが自然ではないでしょうか?あるいはその関数が動作する際の特定のコンテキストに依存した静的な情報ならばクロージャー的な考え方を使ってもよいと思います(ただしJavaが生成できるクロージャーの中のローカル変数は変更不能という他の言語より制約がきついのでコーディングが少々まどろっこしくなるのは否めませんが・・・)
15
+ Javaにはクラスというスコープがあります。クラススコープ内のstaticな情報として考えるのが自然ではないでしょうか?あるいはその関数が動作する際の特定のコンテキストに依存した静的な情報ならばクロージャー的な考え方を使ってもよいと思います(ただしJavaが生成できるクロージャーの中のローカル変数は変更不能であり他の言語より制約がきついのでコーディングが少々まどろっこしくなるのは否めませんが・・・)
16
16
 
17
17
 
18
18