設計問題的最佳方式

我有下面的代碼，我想向類impl中添加一個新的構造函數，而不會對現有代碼進行任何更改。我是否應該使用適配器並編寫自己的包裝器實現，或者有什麼方法可以以某種方式執行，我錯過了嗎？特別ClassImpl領域Class2中需要（使用適配器模式？）設計問題的最佳方式

public interface Class1 { 
    void customise(Configuration configuration); 
} 
public interface Class2 { 
    void customise(DeprecatedConfiguration configuration); 
} 

class DeprecatedConfiguration extends Configuration { 
} 

public class ClassImpl { 

    private final Class2 customizer; 
    private final DeprecatedConfiguration config; 
    // want to deprecate this 
    public ClassImpl(final Class2 pCustomiser) { 
    customizer = pCustomiser; 
    config = new DeprecatedConfiguration(); 
    }  

    // want to add this 
    //public ClassImpl(final Class1 pCustomiser) { 
    // customizer = pCustomiser; 
    // config = new Configuration(); 
    //} 

    public void someMethod() { 
     customizer.customise(config); 
    } 
}

來源

2011-09-08 Scorpion

安德烈暗示的，首選將立即刪除過時的代碼。

做不到這一點，最好的情況是，如果以下所有條件都爲真：

ClassImpl實現了一些接口FooInterface，
所有的消費者依賴於FooInterface而非ClassImpl，
ClassImpl的實例不是由其消費者創建的，而是dependency-injected,

如果是這樣的話，那麼你可以：

寫的FooInterface另一種實現方式，它使用新型
變化依賴注入的配置，使這個新的執行被創建和注入

並且沒有消費者會注意到。

如果不這樣做，你將不得不想出一個更加複雜的解決方案。如果這是一次性交易，我強烈建議不要爲此實例創建一個全新的抽象層。黑客應該清楚地標記爲黑客，而不是僞裝成合法的設計。

來源

2011-09-08 09:57:36 oksayt

我同意，但我不得不不情願地走黑客道路。謝謝。 – Scorpion

，請不要「overengineer」更改爲新的類型。最好的方法是實現新的構造函數並刪除已棄用的構造函數。我懷疑這會在現有代碼中造成太多更正。不必要模式的使用增加了代碼的複雜性和可維護性降低

來源

2011-09-08 09:25:54

+1 - 阿門，兄弟。我們假設您使用的是版本控制系統，以便您可以隨時在需要時返回棄用的類。 – duffymo

好吧，希望我能成爲我的首選。但事實上，這些代碼屬於一個庫，供多個團隊中的其他用戶使用，他們希望通過儘可能少的改變以自己的速度遷移到新版本。你知道滿足圖書館用戶的需求是多麼困難，但我正在努力。 – Scorpion

然後用@Deprecated標記舊的構造函數，並實現一個新的構造函數。您的用戶將準備在下一個版本的lib發佈後立即進行更改 –

設計問題的最佳方式

回答

相關問題