Effective Javaを読むチャレンジ-項目4~5-

項目4 privateのコンストラクタでインスタンス化不可能を強制する

ユーティリティクラスにはインスタンス化をさせないためにprivateコンストラクタを用意しなさいという話。

それはいいんですが、どうにもユーティリティクラスって最終的にパッケージの掃き溜めかってぐらい用途にまとまりのない処理が集まってたり、悲惨になりがちな気がします。運用というか設計というか、プロジェクト内教育の問題でしょうけど。

項目5 不必要なオブジェクトの生成を避ける

この不要なStringオブジェクト生成はコーディング規約で禁止している場合が多いですね。分かりやすいタブーですし。

Calendarクラスは生成コストが高いので有名ですね。sizeofという外部ライブラリを使って測定したら1インスタンス248バイトでした(Java SE 8)。確かに高い。

static初期化子でstatic finalに変更する

サンプルでは1回作ればいいDateオブジェクトを作るためにstatic初期化子を使って日付定数にしています。まあ、この場合は確かにそうすべきでしょう。

ほとんど呼び出されないstatic finalフィールドに遅延初期化を施すのはどうか

コードが複雑になるしパフォーマンス改善にもほぼならないと言ってます。パフォーマンスはシステムごとに変わるのでこの言葉を根拠にはできないですが、よっぽどコストのかかる初期化をやっているならその処理の方の問題だし。その処理を変えられない場合は検討とか?

Adapterクラスのインスタンスも不要な生成を避ける

内部に状態を持たないのが普通なので、確かに。

MapインターフェースのkeySet

Javaソースで確認しました。確かにKeySetは毎回生成してないです。KeySet自身は状態を持ってなくて、扱うのはMapインスタンスの状態なので。

自動ボクシングに注意

実際やってみたけど確かにパフォーマンスの差が大きかったです。自動アンボクシングでもやってみましたが、劇的でないにしろちょっと遅かったですし、両方Longにしても自動ボクシングのときに近い遅さでした。プリミティブ型を使えるならプリミティブ型で、自動ボクシングに注意というのは確かに。

広告
  • LINEで送る