设计问题的最佳方式

我有下面的代码，我想向类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发布后立即进行更改 –

设计问题的最佳方式

回答

相关问题