背景

假如現(xiàn)在你要想一個漢堡，有一個漢堡類：Hamburg。那么一般情況下你會：

Hamburg hamburg = new Hamburg();

情景一：不同參數(shù)數(shù)目的構造器

制作漢堡可以選擇自定義，加肉，加菜，或者不添加，直接默認配方即可，那么會有以下幾個構造器：

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

當你要制作漢堡的時候，看到這么多的構造器，但是卻不知道他們是什么意思，返回的漢堡到底有什么區(qū)別？查文檔又有點麻煩，有沒有更好的解決方法呢？

情景二：不同種類的漢堡

如果有多種漢堡：新奧爾良漢堡，麥辣香漢堡。常規(guī)的做法就是：繼承漢堡類，實現(xiàn)子類，如：

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

但是會有問題：用戶在使用的時候，還得記住你那么多類名，那是不是很麻煩？如果后續(xù)有更多的口味，那是不是要記住更多地類去才能得到對應的實例呢？有沒有更好的解決方法？

情景三：自定義漢堡的做法

如果漢堡的手法讓你非常不滿意，你想要用達芬奇技法來制作漢堡，那么可以怎么做呢？常規(guī)的做法是：

class Hamburg{
 ...
 //默認制作手法 
 private Maker mMaker = new DefaultMaker(); 
 public Hamburg(Maker maker){
  ...
  //使用傳進來的手法對象制作漢堡
  mMaker = maker;
  ...
 }
}

需要重新寫一個構造器，傳入?yún)?shù)來覆蓋原來的制作手法。這樣既有情景一的問題，還有另外的問題是：如果需要自定義的東西多的時候，那么Hamburg里需要維護的代碼就更加的復雜了。

什么是靜態(tài)工廠方法

以上情景問題可以通過靜態(tài)工廠方法來改善。

注意，這里的靜態(tài)工廠方法并不是設計模式中的工廠模式。這里只是使用靜態(tài)工廠方法來代替構造器實例化對象。

顧名思義，靜態(tài)工廠方法，就是使用靜態(tài)方法來構建類的實例，解決使用構造器實例化的各種問題。先看個例子，還是以上面的漢堡為例子，如果需要多種口味的漢堡，那么可以：

class Hamburg{

 //獲取奧爾良口味的漢堡
 public static Hamburg ofAoErLiang(){
  return new AoErLiangHamburg();
 }
 //獲取麥辣香味的漢堡
 public static Hamburg ofMaiLaXiang(){
  return new MaiLaXiangHamburg();
 }
}

//兩種口味的漢堡，通過繼承漢堡實現(xiàn)
class AoErLiangHamburg extends Hamburg{}
class MaiLaXiangHamburg extends Hamburg{}

通過這種方法可以解決的是：用戶需要什么類型的漢堡，可以直接通過Hamburg的靜態(tài)方法來獲取，而無需知道他的子類名字是什么。而如果有更多種口味的漢堡，只需要擴展靜態(tài)方法即可；或者給靜態(tài)方法增加參數(shù)，通過switch來返回對應的口味漢堡。

靜態(tài)工廠優(yōu)缺點

這里的話會結合上面舉的例子，如果忘記了，看到可以返回去看一下。

優(yōu)點

• 解決構造器重載卻不知道各種構造器含義的問題。通過構造方法可以在方法名寫明，那么用戶只需要通過方法名就知道這個方法是返回什么對象。（例如情景一）例如：

//不同的靜態(tài)工廠方法返回不同的實例，通過方法名就知道他們的區(qū)別
//ps：這是android的動畫類
ObjectAnimator animator = ObjectAnimator.ofFloat();
ObjectAnimator animator = ObjectAnimator.ofInt();

• 可以通過根據(jù)用戶的參數(shù)或者調(diào)用不同的靜態(tài)工廠方法來返回具體的子類對象。當后期要更換方法接口返回的子類時，對于用戶來說也是透明的，用戶只是拿到一個父類引用的對象?？梢詤⒖忌厦嫖以诮榻B靜態(tài)工廠方法舉的例子。

Java 8以上，可以在接口中定義靜態(tài)工廠方法，這樣無需知道該接口有多少個實現(xiàn)類，只需要根據(jù)靜態(tài)方法來獲取接口對象即可。

• 重復利用對象，防止創(chuàng)建無用實例。這看起來很像單例，但是比單例要靈活得多?？梢愿鶕?jù)具體的情況，來判斷是否要緩存實例。
• 可以動態(tài)注冊代碼。我們可以通過一組用戶注冊api，讓用戶先把需要的自定義代碼注入，再調(diào)用靜態(tài)方法來獲取自己需要的對象類型。這樣的好處就是不會有一堆很復雜的構造器，內(nèi)部邏輯也可以分離。對應情景三解決的問題

缺點

1. 如果該類不包含public或者protect構造器，那么將無法被子類實例化。因為我們想要用戶通過靜態(tài)方法來獲取對象，而不喜歡用戶通過構造方法來實例化對象。而如果把構造器設置為private，則無法被子類繼承。
2. 無法在javadoc中直接查看文檔介紹，構造器是會直接生成doc的。但是直接通過方法名和參數(shù)名，已經(jīng)可以看懂很多了。
   

靜態(tài)方法命名規(guī)范

小結

在有多種子類或者重載構造器的時候，可以優(yōu)先考慮一下靜態(tài)工廠方法，可以讓我們的代碼更加地優(yōu)雅，也方便我們進行維護。
另外這和設計模式中的工廠模式有區(qū)別，并不是一樣的，要進行區(qū)分。

參考資料

《effective java》

以上就是java 靜態(tài)工廠代替多參構造器的詳細內(nèi)容，更多關于java 靜態(tài)工廠的資料請關注腳本之家其它相關文章！

最新評論