記事『Jakarta プロジェクトの「Torque」を使う』
読んでみると、実業務に使うには全く役に立ちません。
私は以前、Torque + Tomcat + Velocity + Oracle な開発環境で開発した経験があります。
その際には Torque のソースを見て解決したことが山ほどありました。
また、Criteria だけでは力不足なのです。Criteria.Criterion も使わないと
一つのカラムに対する複数の条件での抽出ができないのです。
("column > 0 and column < 10" という条件)
まぁしかし、このような記事が出てきたことを評価すべきかもしれません。
記事『Java Q&A "適材適所" の API 選択術』
激しく既出。そして、勘違いクンが反論の根拠とする表現も見受けられます。
Q3 以外はまぁ、言葉の端々に引っかかるところはあるものの概ね賛成です。
しかし、Q3。これはいただけない。
StringBuffer sbuf = new StringBuffer(500);
マジックナンバーです。500 の数値の意味、理由がないといけません。
定数にしましょう。
パフォーマンスを向上させるためには、必要以上にオブジェクトを
生成しないことが原則です。
その結果一つのクラスで全ての処理をすることに…。
クラス StringBuffer を使う時は、そのつど必要なサイズを
見積もってオブジェクトを生成し、むやみに再利用しない
ほうがよいでしょう。
そして、必要なサイズが大幅に変更になった時、大量の工数が発生する罠。
むやみに再利用しないは賛成。
私としてはそのような小手先のパフォーマンス向上手段は
しない方が良いと考えています。
するのは悪だとまで言い切ってしまいましょう。
# 私が実際に最終手段としてこのような方法を取る時は「必要悪」と
# いう言葉に逃げています。
この記事全体的にパフォーマンス、パフォーマンスと言い過ぎて、
タイトルの『Java Q&A "適材適所" の API 選択術』というのが薄くなっている
気がします。Q3 「文字列のバッファがパフォーマンスに影響すると聞いたんだけど、
どういうこと?」という質問自体がタイトルとなんら関係ありませんし、
(タイトルからすれば)無駄だと思います。
それでも載せるのであれば、小手先のパフォーマンスをただ紹介するのだけではなく、
その対処によるパフォーマンスの影響が微細なこと、そして、
それよりも他の部分(アルゴリズムやデータ構造、またクラス構成)を考え直した方が
大幅なパフォーマンス向上につながることを説明し、小手先のパフォーマンスの
悪影響も紹介できればもっと良い記事になったように思います。
]
