コード補完時代にAPIはどうあるべきか？ - L'eclat des jours(2009-10-03)
_ コード補完時代にAPIはどうあるべきか？ さて（承前）、実は問題は、LogLogのメソッドシグネチャにある。少なくともおれは、そう考える。 おれは常識人だし、みなさんも良識の持ち主だ。 こういう人たちは、以下のようなメソッドをオーバーロードするときに、どう定義するだろうか？ エラー用のログ出力メソッド。当然、ログファイルに出力するメッセージは引数に必要。 でも、例外くらった場合は、例外オブジェクトを引数に付けてくれればメッセージとかスタックトレースとかもログするよ。そのほうがいいよね。 それは、もう、こうするだろう。 interface Log { public void error(String msg); public void error(String msg, Throwable t); } なぜならば、Throwable tはあるかないかわからない、つまりはオプションだからだ
手ぬぐいと納税者は絞れるだけ絞れと行政官は言った - L'eclat des jours(2009-07-03)
_ 手ぬぐいと納税者は絞れるだけ絞れと行政官は言った 流れよわが涙、と警官は言った (ハヤカワ文庫SF)(フィリップ・K・ディック) 昨日書いた後悔先に立たずの公開だが、ぶくまこめで「。与える情報を絞るのではなく、与えた情報を絞らせるように設計すべき。」に対する反応があって、それも正しい反応だと思った。もっとも2行あるのは例示のあやなので、ちょっとそこに突っ込まれてもとは思うが。 たとえば、次に示すBase64EncoderクラスのAPIは何がなんでもおかしい。 public class ComponentInfo { public byte[] getGuid() { ... } public byte[] getCpuInfo() { ... } } ... public class Base64Encoder { public String encodeGuid(ComponentI
5年後に後悔しないJavaプログラムの書き方 - L'eclat des jours(2009-07-02)
_ 5年後に後悔しないJavaプログラムの書き方 ここ数日、死ぬほど後悔しまくっているので、あらためて（というのは、数年前にも一度後悔しまくって、そのときの知見はあらかた処方箋とかコーディングの掟に書いているからだが）後悔しないための書き方をいくつか紹介する。 とにかく、ファクトリメソッドパターンを使うこと。 これは本当に重要。しかも簡単でありながら効果は絶大。 だめな例。 public class FooBar { private Connection conn; ... protected void setup() { ... conn = DriverManager.getConnection(url); ... } urlを指定することや、DriverManagerの実装を交換すれば良いだろうと想定していても（というか、Connectionならそういう方法もあり得るが、そうはいかな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
