靜態工廠方法缺點
靜態工廠方法的主要缺點在於，類如果不含有公有的或者受保護的構造器，就不能被子類化。對於公有的靜態工廠所返回的非公有類，也同樣如此。例如，要想將CollectionsFramework中的任何方便的實現類子類化，這是不可能的。但是這樣也許會因禍得福，因爲它鼓勵程序員使用複合（composition），而不是繼承。
靜態工廠方法的第二個缺點在於，它們與其他的靜態方法實際上沒有任何區別。在API文檔中，它們沒有像構造器那樣在API文檔中明確標識出來，因此，對於提供了靜態工廠方法而不是構造器的類來說，要想查明如何實例化一個類，這是非常困難的。同時，你通過在類或者接口註釋中關注靜態工廠，並遵守標準的命名習慣，也可以彌補這一劣勢。下面是靜態工廠方法的一些慣用名稱：
常用命名規則
valueOf —— 不太嚴格地講，該方法返回的實例與它的參數具有相同的值。這樣的靜態工廠方法實際上是類型轉化方法。
of —— valueOf 的一種更爲簡潔的替代，在 EnumSet （見第32條）中使用並流行起來。
getInstance —— 返回的實例是通過方法的參數來描述的，但是不能夠說與參數具有同樣的值。對於 Singleton 來說，該方法沒有參數，並返回唯一的實例。
newInstance —— 像 getInstance 一樣，但 newInstance 能夠確保返回的每個實例都與所有其他實例不同。
getType —— 像 getInstance 一樣，但是在工廠方法處於不同的類中的時候使用。Type表示工廠方法所返回的對象類型。
newType —— 像 newInstance 一樣，但是在工廠方法處於不同的類中的時候使用。
Type表示工廠方法所返回的對象類型。
第1條：考慮用靜態工廠方法代替構造器
簡而言之，靜態工廠方法和公有構造器都各有用處，我們需要理解它們各自的長處。靜態工廠通常更加合適，因此切忌第一反應就是提供公有的構造器，而不先考慮靜態工廠。