JAVAサーブレットQ&A

>>276 サーバサイドでは安易にシングルトンを使うな、かな。
他にも思い出したら書く。

>276
業務が忙しくなる前に、APサーバ周りのツール類を使いこなせるようにすること

エディターでがんばっちゃう人もいるが生産性が断然ちがう

>>278
なぜ？

>>280 サーバサイドのプログラミングはマルチユーザ、マルチ
スレッドが基本。安易にシングルトン使う人ってマルチユーザ、
マルチスレッド意識してない人が多いのよね。で、後で
synchronized つけようとしても全ユーザの全スレッドがその
シングルトンの部分でシリアライズされちゃったり。

それから、Java のシングルトンはシステムに対してひとつでは
なく、クラスローダーに対してひとつだということを意識して
おかないと後々やばいよ。

実例挙げればきりないけど、今までサーバサイドのフレーム
ワークの中枢部分にシングルトン持ち込んだ莫迦ＳＥのアプリ
開発はことごとく動かなかったという経験則から (俺ではない)。
ツール程度なら問題ないかもしれないが十分注意。

ちなみにそいつは COBOLER。プロシジャ型言語しか設計したこと
ない人に Java の設計させてみると、大抵シングルトンとコマンド
パターンを設計の中核に持ってくるよ。

>>281-282
サブレの経験はないがOOP畑の勘(わら)として、
凄く適切な解説だと思う。

プロシジャを中心に考えちまったら、
(少なくともOOPシステムであるJavaってものは)
全然旨く動かなくなるんだよな。

だから、OOPの効能を機能(=プロシジャ)ベースで説明しよう
などとしている入門書は、全部ドキュだ。焚書しろ焚書。

とりあえずコードレビューする人は grep で static 宣言引っ掛けて、
その変数/メソッドがマルチスレッド対応してるかくらい確認せれ。
大抵何ヶ所か未対応部分が見っかるぞ。個人的には static を使用
する部分には設計責任者の承認ハンコくらい必要だとも思っている
(極論だが; もちろん static final は除外して)。

static じゃないメンバ変数もヤバいと思うぞ？

>>281
激しく同意。ＸＭＬじゃないけどサーブレットにネームスペース
導入して欲しい..ってパッケージ宣言か(w
関係ないけどtomcatでstatic使ったchat作ったら、サーブレット
削除してもずーっとメモリーに残っていてかなりあせった。

>>285 もちろん。とりあえず static はクリティカルにマルチスレッドの
影響を受けやすいというコトで。

>>286 多分オートリロードを期待して前のオブジェクトがメモリ上に残った
ままになったのかな？>>281 でちょと説明不足だったけど static なイン
スタンスはクラスローダーに対して１個ってのはそう言う意味もあった。

>>278
さんきゅ。

使う必要ないとこで、適当にSingletonにしたらはまると。
SingletonってLogin管理するクラスとか、ConnectionPoolみたいなのに
使うと思ってたから、安易なとか言われても想像のつかないとこではあるが。

マルチスレッドなんだから、同期非同期意識してるよな？という意識が
いるってことね。

ログ出力とかキャッシュ機能みたいにシングルトンでまとめて管理しておきたい
部分はどうしても出てくるよ。シングルトンにすべきところとやっちゃいけない
ところの見極めが、よく意識しないと見えにくいかな。なんせ非同期の問題は
単体テスト通っちゃうんだから。

オブジェクトの集約関係があるでしょ。あれを洗い出せば、オブジェクトのイン
スタンスが全ユーザに対してひとつなのか、ユーザごとにひとつなのか、もしく
は毎回使い捨てなのかが明確になるはず。マルチスレッド初心者にはスレッドごと
にインスタンス使い捨て部分を任せたほうが良い。アプリケーションロジックを
実装した Bean を HTTP セッションに入れて、サーブレットからそれをつつく
だけのような設計にしてみ。少なくともその Bean 作る人のスキルをシングル
ユーザマルチスレッドまで落とせるから (だからオブジェクトの関係を意識
しないプロシジャ型設計はサーバサイドに向いていない)。

# 前に書いたエキスパート COBOLERs + 初心者 VB 使いたちのデスマーチは
# 毎回上記の問題を繰り返している…。これもスパイラル開発の一種？ (藁