Please enable JavaScript.
Coggle requires JavaScript to display documents.
2章「オブジェクトの生成と消滅」 (staticファクトリメソッド (メリット (キャッシュできる (都度生成せずにすむ),…
2章「オブジェクトの生成と消滅」
staticファクトリメソッド
コンストラクタの代わりに使う
staticなメソッド内でそのクラスをインスタンス化する
メリット
キャッシュできる
都度生成せずにすむ
メソッド名をつけられるのでわかりやすい
サブタイプのインスタンス化をするときとかね
非公開クラスのインスタンス化が可能
Collectionとかは45の非公開クラスがあるらしく
それはファクトリメソッドを通して生成される
方はあくまで公開されているCollectionになるのかな
http://kouki-hoshi.hatenablog.com/entry/2015/12/12/215851
このサイトはめちゃくちゃわかりやすい
使われなくなったオブジェクト参照を取り除く
stackにおいて、要素をpopした場合はそのstackの要素への参照は使われるべきではない
参照を保持し続けるとメモリリークが発生する
クラスが独自のメモリ管理をしている場合は、メモリリークに注意を払おう
element[0]とelement[1]があったとして、1をpopする
しかしelement[1]への参照は残ったままになるため、nullとかを入れて回避する。
もし使われてもヌルポで落ちる
弱い参照を使う
WeakHashMapを使う
エントリが無効となった場合は勝手にGC対象になる
多くのコンストラクタパラメータを必要とする場合はビルダーを使う
従来
テレスコーピングコンストラクタパターン
パラメータに合わせ、複数コンストラクタを作成していくこと
少ないパラメータを受け取るコンストラクタは、次に多いコンストラクタを呼び出す。あとはそれを繰り返していく
JavaBeans
必要なパラメータのsetterをセットしていく
JavaBeansの欠点
セットしている途中のオブジェクトの状態は不整合ということ
セットするべき値がすべてセットされて正常なオブジェクトとしてみなしたいが、それを矯正することはできない
せいぜいプロパティをfinalにするくらい？
ビルダーパターン
テレスコーピングコンストラクタの安全性とJavaBeansのか毒性を組み合わせた方法
対象のクラス内にstaticのBuilderクラスを作成する
Builderクラス内でも同等のパラメータをプロパティとして持つ
クライアントはBuilderクラスを必須パラメータを取るコンストラクタで生成する（この段階ではまだBuilderオブジェクト）
各オプションプロパティの設定は、セットしつつ、最後にBuilerオブジェクト自分自身を返す
でこのセットメソッドを使用しても、対象のクラスは生成しない
最後の最後に、build()メソッドを使って対象のクラスにプロパティにBuilderでセットしていったプロパティをセットして生成して返す
インスタンス化不可能を強制する
Utilクラスなどstaticのみで構成されるクラスはある
別に設計として間違っているとも言えない
どうやってインスタンス化されることを防ぐか？
abstracクラスにする
abstractクラスはインスタンス化出来ないが、サブクラスを作成してインスタンス化されそうなのでだめ！
コンストラクタをprivateにする
コンストラクタでExceptionを発生させる
これは、privateだったとしてもクラス内のメソッドから呼び出せるため（staticファクトリメソッドとか危ないからね）
