俗に「詰め Java 」と謂われる、ある種のゲームがある。基本は以下の通り。


　この「詰め Java 」、普通に「ただ動くコード」を書くのの三倍以上の時間ないし手間がかかります。そのかわり、日常的に「詰め Java 」レベルでコードを書いていて、その結果コードがある程度蓄積されてくると、全体の開発効率は三倍なんていうものではなく五倍十倍で効いてくるので、トータルの開発効率としてはかなりの向上が期待できます。

　ただこれ、「不必要にハマる」っちゅーか、「煮詰まると長い」っちゅーか、このスタイルに慣れちゃうと、「とりあえず動かしたい」っつー時にはあんまりありがたくないっつーか瞬発力が落ちるっつーか、嬉しくない状況に陥ったりします。

　以下はけっこう専門的な話なので、わかんない人は適当にパスしてください。

　具体的には、今現在 RDBMS （俗に“データベース”っちゅー奴です）のコネクションを引っ張ってくる部分のコードで煮詰まっちゃってるのだな。複数のデータソースからコネクションを引っ張ってくる場合に、個々のデータソースをどこに持たせるかで激しく悩んでしまうわけです。
　 Java には「抽象クラス（ Abstract Class ）」っつーものがあります。具体的には「継承（ extend ）してからでないと使えない Class 」です。これ、 C 言語でいう「宣言」みたいなものかと思いきや、実は単に「継承してから使ってね」っていうだけの話であって、変数領域だのクラス実体だのがモロに取られてしまいます。

　これって、どういう意味か。

　そうなんですよ。「“抽象”クラス」っつーくらいだから、 static なメンバ変数の領域は、 extend して宣言したサブクラスごとに取られると思っちゃうじゃないですか。だけど、実際にはスーパークラスである Abstract なクラスの中の領域が共通して使用されるものだから、「こっちのサブクラスで static なメンバ変数を書き換えちゃうと、あっちのサブクラスで参照してる内容まで変わっちゃう」ってな事が起きるのね。

　で、「そうじゃなくって、『あるクラスを継承したクラスの中で、各サブクラスごとに static な変数領域が自動的に（＝明示的に書かなくても）確保される』みたいな形にできないか」とか考えだすと、「シングルトン実装」だとか「コンクリート・クラスとインタフェースの組合せによる抽象クラスの定義」だとか手法を組合せてあーだこーだと試しながら何日も悩む（そして、その結果として肝心の実装作業がまるっきり進まない）、ということになってしまうわけです。(T_T)

　「面白いし勉強にもなるんだけど、必ずしも実戦で役立つとは限らない」っつーところも、「詰め Java 」の“詰め” Java たる所以（ゆえん）かもしれません。