爲什麼有些類限制直接實例化？

Question

我遇到了不允許直接創建實例的各種類。相反，我們必須從其他類的靜態方法或自己的靜態方法創建它們的實例。例如：

B b = A.getB(); 

或

B b = B.getInstance(); 

什麼原因的背後是什麼？

他們爲什麼不直接允許創建實例，如：

B b = new B(); 

Answer 1

有些類想要控制它們的實例化方式，因此保護它們的構造函數免受公共使用。使用像getInstance這樣的靜態工廠方法可以讓他們將控制權保留在自己的代碼中。

有一百萬個原因想要做到這一點。

編輯：爲了解決您的評論，這不能在構造函數中完成，因爲new運營商將總是創建一個新的實例（除非拋出一個異常）。在調用構造函數時，構造函數中的代碼控制是否實例化對象爲時已晚。

Answer 2

這些都是Singleton Pattern的一個例子。他們通常有私有構造函數的方法，但在我的例子中，他們使用保護來防止實例化。

抽象類也不能被實例化。

Answer 3

當對象有一個複雜的創建邏輯，設計師代表創建對象，以specific objects 這是一致的single responsibility principle：我們的目標是允許對象忽略其創作所需要的結構和程序。

如果不使用Factory，複雜對象的創建將需要具有太多參數的長構造器。

在getInstance()的情況下，設計人員希望在整個應用程序中都有一個對象的單個實例：它是Singleton pattern，它等同於一個全局變量。

Answer 4

兩者都是creational patterns的實施方式，即處理對象創建機制的模式，試圖以適合於情況的方式創建對象。

• 第一個例子看起來像Factory method pattern：定義一個接口用於創建對象，讓子類決定將哪一個類實例。工廠方法讓類將實例化推遲到子類[Gof]。

• 第二個示例是Singleton pattern：一個只能創建一個類的單個實例的工廠。

他們不允許直接與new創建實例，因爲他們正是瞄準控制創作是怎麼做來解決特定的問題：限制一個類的實例化一個對象的單身，讓子類決定爲工廠實例化哪個類。

Answer 5

一些使用情況：

1. 同工廠模式只有對象的接口將是可見的，實現本身可作爲選件和工廠改變。
2. CreateInstance方法確實不能在構造函數
3. 內完成的類可以使用一個Singleton此對象始終在幕後一些額外的工作返回相同的實例