Effective Javaを読むチャレンジ-項目3-

項目3 privateのコンストラクタがenum型でシングルトン特性を強制する

タイトルからして飲み込みづらいっす・・・結論だけいうと昔は何やかんやあったけど今はシングルトンならenumシングルトン!という話なんですが。

シングルトンのテストは困難

大昔、どうしても上手くテストできなくて、ケースごとにテストクラス作って1クラスずつ起動しなおしてテストしてた記憶が。そんなテストの仕方はねえって言われましたが、他に方法あれば教えてくださいと言ったら向こうも折れた。今はmockitoでどうにかする方法があるようです、mockitoは知っとかないと。それならリフレクションでprivateコンストラクタにアクセスして・・・ってのが防がれてたらやっぱり無理か。本書ではそういう攻撃を防御したい場合についても言及してます。

2つのシングルトン

こんなインスタンスを定数化する方法と、

こういうファクトリメソッドにする方法が昔はあったよ、ということです。筆者は両者の長所を挙げたうえで、たいていの場合、ファクトリメソッドの長所は求められてないと言っています。スレッドごと違うインスタンスを生成したいシングルトンって何かあるかな?スレッドごとに違う設定をしたいシステムの設定ファイルを全部キャッシュしたくないとき・・・とか?

シングルトンをシリアライズ可能にするなら

本書の最後の方の項目でシングルトンクラスにSerializableを実装するならそれはもうシングルトンじゃない、と言ってます。デシリアライズするときに再インスタンス化するから別物じゃん、ということですね。シングルトンをシリアライズ可能にする方法はチェック。

enumシングルトン

これだけでシリアライズ可能になるし、リフレクション攻撃の際にもシングルトン特性を保持(インスタンスの複数生成を阻止)できるとあります。

これはすごい。筆者もこれが最善と強く推してます。enumについてはJava言語仕様の中で重複インスタンスを生成しないことを保証する、とありますし、問題ないのでしょう。enumのリフレクションは試しておきたい。

広告
  • LINEで送る