Javaの道 Javaに関する
　ニュース｜Java基本｜Servlet・JSP｜オープンソース｜FAQ｜掲示板
Javaの道 >  掲示板 >  掲示板（Bridgeパターンについて）
閲覧数：669
掲示板（Bridgeパターンについて）
名前
匿名
題名 Bridgeパターンについて
質問内容

質問を評価する
(0ポイント)
実装のクラスにおいて文字を増加させ表示するクラス
(CharDisplayImpl),文字列を表示するクラスするクラス
(StringDisplayImpl),ファイルの内容を表示するクラス
(FileDisplayImpl)があります。

機能のクラスには一度だけ表示や、ランダム表示、回数
を指定して表示させる機能を持つクラスがあります。

文字列を表示するクラスには文字列を保持するフィール
ドにStringBuilderを利用しています。

一度だけ表示、回数指定して表示を呼び出した場合、
一度だけ表示の文字列を保持しており、回数を指定して
表示する時に余分に一度だけ表示が表示されてしまいま
す。

表示し終わった時にbuffer.setLength(0)をして保持内
容を一旦クリアすると問題なく欲しい結果となるのです
が、どこかのページには、StringBuilderは使い回さな
い方がよいと書いておりました。

やはり、呼び出しの際に毎度、new StringBuilder()を
した方がいいのでしょうか。
質問日時 2012-12-06 11:56:19
名前
匿名
回答内容

回答を評価する
(0ポイント)
StringBuilderを使い回すというよりかは複数スレッドからの同時アクセスに対応していないって話。

StringBufferもStringBuilderもミュータブルだけどStringBufferは原子性が保証されている。
※StringBufferからsynchronizedが外されたのがStringBuilderである。

なのでシングルスレッドの場合にはStringBuilderの方が速い。

ということでシングルスレッドの場合には特に考える必要はない。
回答日時 2012-12-06 19:55:34
名前
匿名
回答内容

回答を評価する
(0ポイント)
・外側のクラスが別のインスタンスかつ使い回さない
・外側のクラスで排他掛けてる
・アプリ的に複数スレッドが同時にアクセスしない
なんてケースなら、StringBuilderをフィールドにしても関係な
いよ。
あくまで、編集しようと思ったときに別のスレッドが編集
「中」なのがまずいだけだから。

スレッドローカルは…いまだに納得行くサンプルを見たこと
がない。
10何年Javaやってきて使ったことないし。
「最初の設計が悪かっただけじゃん？」と感じる。


もっとも、今回の「余分に一度」はそういう話じゃなくて、
単にロジックの問題って気がするなー。
ソース見ないと誰にも分からないけど。
回答日時 2012-12-06 21:13:26
名前
匿名
回答内容

回答を評価する
(0ポイント)
>あくまで、編集しようと思ったときに別のスレッドが編集
>「中」なのがまずいだけだから。

 排他は可視性も考慮すべき。
 通常はsynchronizedで原子性に可視性も内包されるので
 問題ないけど。あくまで表現の話ね。

スレッドローカルはたまにしか使わないけどキャッシュするようなオブジェクトとかの場合とかに使ったことがある。オブジェクトは使い回したいけどフィールドはスレッド毎に固有で処理したいとかの場合に。

小さなシステムだと問題ないけどバカでかいシステムだとオブジェクトを都度生成も侮れないし。

それに１０何年も前にはスレッドローカルも無いしね。
「最初の」ってのもそのときには最新の設計だったかもしれない。 
回答日時 2012-12-06 21:41:47
名前
匿名
回答内容

回答を評価する
(0ポイント)
いや、「スレッドごとのオブジェクト」自体が不要と言った
んじゃなく。
ThreadLocalとクラス名で書けば良かった。
あんな可読性の悪い形で入れた理由と、それをあえて使う理
由が分からん、てこと。
回答日時 2012-12-06 22:13:15
名前
匿名
回答内容

回答を評価する
(0ポイント)
スレッド毎のオブジェクトなどとは言っていませんが…？？

キャッシュしているオブジェクト内のThreadLocalのフィールドってことですが…

つまり、システムの全スレッドでキャッシュオブジェクトは使いまわすけどそのオブジェクトが持つインスタンス変数はスレッド固有にしたい場合ってこと。

それをあえて使うような場面に遭遇しなかったというのはリソースというものを意識したことがないということですか？
それとも意識する必要なんかないほどのリソースを持っているかのどちらかでしょう。

資源というのは無限ではないのです。
回答日時 2012-12-06 22:25:51
名前
匿名
回答内容

回答を評価する
(0ポイント)
リソースを無限だなどと思ったことはないよ。
これでも8bitの頃からやってる人間だし。

そのキャッシュが、staticなMap<Thread, Object>とどう違う
のかってことなんだけど。
回答日時 2012-12-07 12:32:19
名前
匿名
回答内容

回答を評価する
(0ポイント)
>そのキャッシュが、staticなMap<Thread, Object>とどう違う
>のかってことなんだけど。

キャッシュオブジェクト自体はそんな定義はしません。
キャッシュが持つThreadLocalなフィールドってのならわかりますけど。

で、そうだと仮定して上記だと自身のThreadの判定を常にするんですか？？
それにそれだとThread管理も必要になりませんか？
ガベージコレクトのタイミングまで見失いそうな気がしますし、わざわざ標準ライブラリが提供してるのにそれを使わないのって意固地にしか思えません。

仕様だけで見れば満たせるでしょうがそれをわざわざ自分で実装するメリットが全く見えません。
回答日時 2012-12-08 09:18:24

質問から6ヶ月以上経過しているので、回答を書き込むことはできません。



このページのトップへ
　ニュース｜Java基本｜Servlet・JSP｜オープンソース｜FAQ｜掲示板
Javaの道_CopyrightJavaの道