■1 「ダイコン時代の設計手法 - ロジックをどこに置くのか」

酔っ払ったときに私がtakaiさんといつも話していたのはこの話題。

そうはいっても「Tell, Don't Ask」的な手法を取り入れる余地はあると思う。が、私にはサービスに置くべきロジックと、エンティティに置くべきロジックの判断基準も示せなければ、各々のロジックを示す名前もつけられないので、言葉が続かない。時間ができたら少し他人の褌で独り相撲をとろうかな、とは思っているけれど。

私のことはどうでもよくて、ひがさんによるこれら「実践ダイコンシステムデザイン」、というか「Expert One-to-One DICon Design and Development」(まさにOne-to-One!)のシリーズは必読。

■2 Safariに入ったらmanningが充実する罠。

MEAP*1なんてのも始められてしまった。Amazonでの購入すらためらわれる。Safariで書籍費削減の野望は潰えてしまうのか……。

• 『Hibernate in Action』
• 『JUnit Recipes』

Manningのサイトでのラインナップをみると、イキオイがあるなー、と思う。

Safariトークンの謎を解く

わーい。貧乏性なので、ビビってまだひとつも使ってなかったので、助かりました。規約ちゃんと読め、って感じだが。

■3 「ダイコン時代の設計手法 - 例外処理」

otsukaさんのところに寝ぼけたコメントをなすりつけたりしているので、以下も寝言のようなものだが:

折りしもIBM dwにも「Java theory and practice: The exceptions debate」が出ていたところ(「Javaの理論と実践」シリーズなのでいずれ翻訳されるでしょう)。検査例外派、実行時例外派、中庸派と整理されている。

私は「catch禁止。間違いない」とまでは踏み切れない、中庸派という名の日和見主義者なので、catchしたうえで機能としてやることがある(再実行とか、プレゼンテーションに特殊な表示をさせたいとか。項目40*1参照)のなら、検査例外を使いたい。といっても、この場合は注意深く設計する必要があって、うっかりすると項目39*2違反になってしまう。状況によっては設計者間での意思疎通のコストもバカにならない(これは分岐か?例外か?)。つまり、「よほど例外の設計に自信のない限り」のケースなわけだ。道理で。火傷したこと一度ならず。

ちなみに上記の「項目:nn」は『Effective Java』。イマドキはこのあたりに関しても、もっと良い(というのは日本語が読みやすい)書籍はあるのかな？

■4 higaさんによるダイコン時代の設計方法 - tpircs

tpircsさん作成(偉い!!)。