java静的工場は多参コンストラクタの適用状況と優劣を代替します。

背景
今ハンブルクがほしいなら、ハンブルク類があります。普通なら、

Hamburg hamburg = new Hamburg();

情景一：異なるパラメータの数のコンストラクタ
ハンブルクを作って、自分で注文して、肉を加えて、料理を加えて、あるいは添加しないで、直接に調合指図書を黙認すればいいです。次のいくつかのコンストラクターがあります。

Hamburg();
Hamburg(Meat meat);
Hamburg(Meat meat,Vegetable vegetable);

ハンブルクを作る時、こんなにたくさんのコンストラクションを見ましたが、彼らがどういう意味か分かりません。帰ってきたハンブルクにはどんな違いがありますか？文書を調べるのは面倒くさいですが、もっといい解決方法がありますか？
情景二：種類の違うハンブルク
多様なハンブルクがあれば、ニューオーリンズ、ハンブルク、マクラージュ、ハンブルクがあります。慣例としては、ハンブルク類を継承し、サブクラスを実現することです。

class xinaoerliangHamburg extends Hamburg{}
class mailaHamburg extends Hamburg{}

しかし、問題があります。ユーザーが使う時は、あなたのような多くの種類の名前を覚えなければなりません。それは面倒くさいですか？もっと味が続くなら、もっと多くの種類があってこそ対応できる実例を覚えておくべきですか？もっといい解決方法がありますか？
情景三：ハンブルクの作り方をカスタマイズします。
もしハンブルクの手法が気に入らないなら、ダビンチの技法でハンブルクを作りたいですが、どうすればいいですか？一般的なやり方は：

class Hamburg{
 ...
 //       
 private Maker mMaker = new DefaultMaker(); 
 public Hamburg(Maker maker){
  ...
  //              
  mMaker = maker;
  ...
 }
}

構造体を新たに書く必要があります。着信パラメータはもとの製作手法をカバーします。このように情景の問題があって、また別の問題があります。もしカスタマイズが必要なものが多い場合、ハンブルグにはメンテナンスが必要なコードがさらに複雑になります。
静工場の方法は何ですか？
以上の状況問題は静的工場法により改善できます。
ここでの静的工場法は設計モードにおける工場モードではないことに注意してください。ここでは，構造体の実用化対象の代わりに静的工場法を用いただけである。
名前の通り、静的工場法とは、静的方法を用いてクラスの実例を構築し、コンストラクタの実用化を用いたさまざまな問題を解決することである。例を見てみます。それとも上のハンブルクを例にして、いろいろな味のハンブルクが必要なら、それでいいです。

class Hamburg{

 //          
 public static Hamburg ofAoErLiang(){
  return new AoErLiangHamburg();
 }
 //         
 public static Hamburg ofMaiLaXiang(){
  return new MaiLaXiangHamburg();
 }
}

//       ，        
class AoErLiangHamburg extends Hamburg{}
class MaiLaXiangHamburg extends Hamburg{}

この方法によって解決できるのは、ユーザが必要とするタイプのハンブルクは、直接にHamburgの静的な方法によって取得することができ、彼のサブクラスの名前は何であるかを知る必要がないことである。もっと味があるハンブルクなら静的な方法を拡張すればいいです。あるいは静的方法にパラメータを追加して、switchを通じて対応する味のハンブルクに戻ります。
静的工場の長所と短所
ここは上に挙げた例に合わせて、忘れたら戻ってみてもいいです。
長所

コンストラクタの重負荷を解決しても、様々なコンストラクタの意味が分かりません。構造方法によって方法名を明記することができますが、ユーザーは方法名だけでこの方法がどのようなオブジェクトに戻るかを知ることができます。例えば、情景一）は、例えば

である。

//                ，             
//ps：  android    
ObjectAnimator animator = ObjectAnimator.ofFloat();
ObjectAnimator animator = ObjectAnimator.ofInt();

は、ユーザのパラメータに従って、または異なる静的工場法を呼び出して、特定のサブクラスオブジェクトを返すことができる。後期に方法インターフェースを交換して返すサブクラスの場合、ユーザーにとっても透明であり、ユーザは親タイプの参照の対象を得るだけである。上記を参考にして、静的な工場方法の例を紹介します。

Java 8以上は、インターフェースに静的工場法を定義することができ、このようにインターフェースにはいくつかの実装クラスがあるかを知る必要がなく、静的な方法に従ってインターフェースオブジェクトを取得するだけでよい。

は、無駄なインスタンスの作成を防ぐためにオブジェクトを繰り返し利用する。これは一例に似ていますが、一例よりずっと柔軟です。具体的な状況に応じて、インスタンスをキャッシュするかどうかを判断しても良い。

は、コードを動的に登録することができる。私たちはユーザーのグループを通してappiを登録して、ユーザーに先に必要なカスタムコードを注入させて、静的な方法を呼び出して、自分の必要なオブジェクトタイプを取得することができます。このような利点は複雑なコンストラクタが多くないし、内部のロジックも分離できるということです。情景三解決の問題に対応します。
欠点

このクラスにpublicまたはprotectコンストラクタが含まれていないと、布団類の実用化は不可能です。私たちは、ユーザが静的な方法でオブジェクトを取得したいので、ユーザがオブジェクトを構成する方法で実装するのが嫌です。コンストラクタをプリヴァに設定すると、布団類を引き継ぐことができません。

はjavadocで直接文書の紹介を見ることができません。構造体は直接docを生成します。でも、直接に方法名とパラメータ名を通して、もうたくさん分かります。

静的方法命名規範
メソッド名
意味
from Xxx 
タイプ変換
オフxx
複数のパラメータの集約
valueOf
from ofと類似しています
get Instance
 一例を取得します。例のタイプは方法パラメータによって記述されます。
get NewInstance/create
新しいインスタンスを取得します。
getType
主に工場法において異なる対象を取得するためのもの（設計モードにおける工場法に該当する）
newType
対応するクラスのオブジェクトを新規作成します。(デザインモードの工場方法に属します。)
タイプ
 上の二つの簡略版
結び目
多種類やリロードコンストラクタがある時は、静的工場の方法を優先的に考慮して、コードをより優雅にして、メンテナンスにも便利です。
また、設計モードの工場モデルとは違って、区別があります。
参考資料
『effective java』
以上はjava静的工場が多参コンストラクタの詳細を代替しました。java静的工場に関する資料は他の関連記事に注目してください。