Builder模式，具有公共構造vaild

我知道有關於建造者模式的幾個問題。
- Use builder pattern from the constructor in a subclass
- When would you use the builder pattern
- Java improving builder pattern on a specific class
- Builder design pattern why do we need a director Builder模式，具有公共構造vaild

到目前爲止，我用生成器模式類似descripted布洛赫項目2.

昨天，我改變了一些小細節。我添加了一個默認值的公共構造函數。因此，您可以使用Builder作爲複雜對象，也可以將簡單對象的構造器用於必要的值。

public class Blub { 
    private final String id; 
    public Blub(final String id) { 
    this(Blub.Builder(id)); 
    } 

    private Blub(Builder builder) { 
    this.id = builder.id; 
    } 

    public static class Builder { 
    private final String id; 
    public Builder(final String id) { 
     this.id = id; 
    } 

    public Blub build() { 
     return new Blub(this); 
    }  
    } 
}

但我不知道這是否有設計缺陷。因爲如果我最終確定課程，我相信沒有缺點。因此，在簡單的情況下，可以調用Blub構造函數。

new Blub("1a");

代替

(new Blub.Builder("1a")).build();

但是，如果我不定型類將有可能擴大，並盡一切樣的東西在新的構造函數。而且我不確定現在是否沒有這種情況。任何想法？

來源

2013-08-24 Christian Lutz

如果有人擴展類，這是他們的工作，以確保他們這樣做正確。我不認爲如果他們做得不好，我會擔心會發生什麼。你不能修正愚蠢。對於這個問題，他們可以覆蓋每個班級的每種方法，做與其應該做的事情完全相反的事情 - 你也無法阻止。所以不要擔心。 –

@GabeSechan哇，我不能不同意更多。類應該被設計爲繼承，否則它應該被禁止。您正在創建軟件中的未來錯誤。 –

@Christian製作Blub最終的問題是什麼？ –

有一兩件事，我經常做的是提供一個建設者和靜態工廠方法建立共同的簡單情況。這樣你仍然可以擁有一個私有的構造函數，並且可以通過乾淨的方式來構造默認情況。

Blub blub = Blub.createWithId("id");

這也可以讓你添加了一些靜態工廠方法，而無需有多個構造函數或構造與混亂的參數。

來源

2013-08-25 00:44:12 dkatzel

如果你要使用（對於這個問題或工廠模式）一個生成器，它通常是反直覺有參數的構造函數，以及（除非他們是依賴關係，並且您使用IOC）。你基本上打破了正交性和乾燥原則。生成器和工廠模式通常用於解決創建實例不平凡或者容易出錯的構建挑戰。

在你的情況，這似乎並不如此。

是不是存在設計缺陷？不可以。它可能會導致API變得混亂嗎？絕對。特別是隨着時間的推移，越來越多的代碼發散並開始使用方法A和B.您是否要向新開發人員解釋何時應該使用方法A創建對象或何時應該使用方法B？

來源

2014-02-03 11:32:27

Builder模式，具有公共構造vaild

回答

相關問題