Effective Java第2版 購入

Effective Java 第2版 (The Java Series)

Effective Java 第2版 (The Java Series)


ジュンク堂にて購入。まだ全然読んでないけど、シングルトンを実装するために単一要素のenumを使うとかなかなか楽しげな内容が。
今のところ、項目2*1で異論というか、微妙な所が。
テレスコーピング・コンストラクタパターンはいいとして、JavaBeansじゃなくなるけど、必須項目をコンストラクタで設定するようにすればJavaBeansパターンはマシになるんじゃないかな。
ただ、ビルダー使え、って根本的な所は大賛成だけど。

*1:数多くのコンストラクタパラメータに直面した時にはビルダーを検討する

UMLは

UMLは設計のためのツールじゃなくて、説明のためのツール*1、考えをまとめるためのツール*2だと思う。
UMLを使って設計するんじゃなくて、設計書に参考程度にUMLを書くような感じ。

*1:未来への自分への説明含む

*2:これを設計と呼ぶなら設計のためのツールだけど、これは設計ってほどのもんじゃないしなぁ

GCにはまる

ぬるり。: COM クライアント実装の道程 for TaskScheduler その番外編2 〜 COM オブジェクトと GC とファイナライザを参考に、Excelを操作するCOMオブジェクトのラッパーを書いたんだけど、見事にはまった。

using (IExcel excel = new Excel())
using (IWorkbook book = excel.Books.Open("hoge.xsl"))
using (IWorksheet sheet = book.Sheets[1])
{
    // sheetに対して操作を行う
}


こんな感じでCOMオブジェクトを扱うときの面倒なtry-finallyを不要にしたんだけど、なんか動きがおかしい。しかもほぼ100%再現はするんだけど、場所がばらばら。
デバッグモードで例外の発生時点で中断させてみると、呼び出し履歴がすごく浅い、と言うか、メインから辿れないことが判明。
ステップ実行してもなんか急に例外が発生するので、スレッド周りか?と思いつつも自分でスレッドなんて開始してないし、GUIじゃないし・・・
で、Disposeメソッドがデストラクタから呼び出されていることを思い出し、GCの可能性に思い当たった。
試しに、usingブロックの最初でGCを起動してみると、見事に再現。


excel.Booksとか、book.Sheetsとかで一時オブジェクトを生成してるのが悪かったみたい。
と言うことで、生成する側のオブジェクトに生成したオブジェクトを保持させておくことで解決。

HAVING句知らないんだ・・・

集計結果でフィルタしたい、って、そのためにHAVING句があるんですが・・・
他にも、ORDER BYしたあとにGROUP BYしたい・・・って、自分で何がしたいかわかってないんじゃないかとしか思えない。