Question

以下是一位同事提出的实际情况，这种情况引起了我的兴趣：

public DoSomething()
{
    //Do Stuff
    var assembly = Assembly.LoadFrom("Path");
    //Do More Stuff
}

所以，为了模仿这个，你有两个选择

创建internal virtual方法：

internal virtual IAssembly LoadAssembly(String path){...Load Here...}

或者，添加一个可以传入的新类

public class AssemblyLoader
{
    public virtual IAssembly LoadAssembly(String path){...Load here...}
}

这两个选项似乎都是一个问题，因为第一个看起来它应该是一个私有方法，而第二个似乎是为一个简单的静态调用创建一个包装器的过度设计？

所以，我想我会把它带到社区。我正在寻找最实用的方法，同时保持单位 - 稳定。

这类似于this SO question，但我想深入研究它。

Answer 1

问题太笼统，所以很难回答。

一般来说，我认为你的问题是人为的。您认为为第三方服务创建包装器是过度设计的，但同时说这个包装器是解决实际问题的方法。如果它解决了一个真正的问题，那听起来不像过度设计，包装器实际上听起来就像是一个好的设计。

当您需要在无法控制的代码上配置状态时，为第三方服务创建包装器通常很聪明。它的味道并不像你想象的那么糟糕。事实上，我没有看到另一种方法来做到这一点。无论你如何分割它，无论你是在嘲笑某些第三方库，使用一些反射魔法，还是使用你的目标解决方案，这一切都归结为包装真正的第三方api。

如果你的直觉仍然说包装这个外部api过度设计，也许你需要重新构建你的问题。问问自己，是否应该测试此代码？

Answer 2

这里很难进行概括，但加载程序集之前和之后的注释表明DoSomething方法可能违反了Single Responsibility Principle。也就是说，代码做了太多事情。编写代码有很多方法可以避免这种情况，并且在你的问题中提到了其中的两个。我想我会遵循Greg的建议，并在这里实施依赖注入。根据这个例子，我很难说出什么是和不是过度设计。

可测试性与过度设计？

2 个答案: