13/11/05 22:51:45.82
>>60
const使ってるとコンパイラが(中で)定数扱いにしやすい
あと(ライフサイクルが短くなって)死にやすい
64:デフォルトの名無しさん
13/11/05 22:52:50.38
>>61
> 言ってる意味がよくわからんな
オラクルにでも聞いてください。
オートデプロイは開発環境用につくられてるって書いてあるんだから。
っていうか、実際にstatic使ったら問題が起きるんだろ？
それがオートデプロイを実運用で使うべきではない理由の一つじゃん。
> staticは本来極力使うべきではない。
なんでだよｗ
65:デフォルトの名無しさん
13/11/05 22:53:57.91
>>61
訂正
☓ APIをstaticにしなくとも
○ APIをstaticにするにしても
66:デフォルトの名無しさん
13/11/05 22:55:23.04
もはや、”センス”って言っていいのかもしれんな。
オートデプロイを使って開発している時に、
オートデプロイができない場合がちょくちょくあるのは
わかりきってるじゃん。
その時点で実運用で使おうなんて思わないよ普通。
オートデプロイの事を考えて開発するなんて本末転倒。
67:デフォルトの名無しさん
13/11/05 22:55:45.73
>>64
たいていのやつはstaticをグローバル変数みたいな使い方しているだろ。
グローバル変数を排除しスコープの局所化でリソースを有効に使うべきだから。
68:デフォルトの名無しさん
13/11/05 22:56:01.12
すべてstaticにするべき。
69:デフォルトの名無しさん
13/11/05 22:56:35.34
>>67
正しいstaticの使い方をしてください。
70:デフォルトの名無しさん
13/11/05 22:57:48.11
C/C++でグローバル変数を使いまくってウンココード書いているようなやつがstatic
信者だからだよ。
71:デフォルトの名無しさん
13/11/05 22:58:53.81
>>64
なんでだよってMockオブジェクトとか作れなくなるだろ
こんな簡単な事も理解できない奴が
なんでオートデプロイなんて使ってるんだ？
72:デフォルトの名無しさん
13/11/05 22:59:31.36
staticはインスタンスが無くても呼び出せる。
だからすべてstaticにするべき。
73:デフォルトの名無しさん
13/11/05 23:02:08.52
小規模開発でオートデプロイ
これなら全部staticで問題ない
74:デフォルトの名無しさん
13/11/05 23:22:56.75
例えば内部クラスは必要が無い限りstaticにすべき。
ここでも非static信者はstaticを避けるの？
75:デフォルトの名無しさん
13/11/05 23:26:12.93
>>74
避ける。
76:デフォルトの名無しさん
13/11/05 23:26:20.88
オートデプロイもクラスのreloadableも残念ながら現状あまりあてにならない。
77:デフォルトの名無しさん
13/11/05 23:26:16.36
>>74
それ、もしよければ理由を教えて欲しい >>9 もそうしてるね
78:デフォルトの名無しさん
13/11/05 23:28:26.18
staticこそが栄光であり神の教えでもあるから
Javaに幸あれ
79:デフォルトの名無しさん
13/11/05 23:28:54.31
親オブジェクトへの参照を持つから。
80:デフォルトの名無しさん
13/11/05 23:36:18.69
宇宙空間ならstaticじゃなくても良い可能性がある
81:デフォルトの名無しさん
13/11/05 23:57:35.13
>>79
ごめんここまで書いてわからなくなったURLﾘﾝｸ(ideone.com)
インナークラスにどう追加したら｢親オブジェクト」（？？？？）の参照を拾えるの？
82:デフォルトの名無しさん
13/11/06 00:13:02.17
>>80
地球では第１コンパイル以前の処理をstaticとしていますが、
宇宙には第２コンパイルも普通に使われ
第Nコンパイルに至ってはインタプリタと同等です。
どういうことかというとstaticはありません☆
83:デフォルトの名無しさん
13/11/06 01:18:29.47
>>81
staticでない内部クラスからは「親オブジェクト」のフィールドやメソッドに普通に
アクセスできる。この場合内部クラスでthis.mとかやれば自分自身が返る。
参照がほしければ親オブジェクトのクラス名.this。この場合はC.this。