3

这是一位与我感兴趣的同事实际提出的情况：

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...}
}

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

所以，我想我会把它带到社区。我正在寻找最实用的方法，同时保持单元可测试。

这类似于这个 SO question，但是我真的想更深入地研究它。

4

2 回答 2

3

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

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

当您需要在您无法控制的代码上配置状态时，为 3rd 方服务创建包装器通常是明智的。它没有你想象的那么难闻。事实上，我没有看到另一种方法来做到这一点。无论你如何分割它，无论你是在使用一些 3rd 方库进行模拟，使用一些反射魔法，还是使用你有目的的解决方案，这一切都归结为包装真正的 3rd 方 api。

如果您的直觉仍然认为包装这个外部 api 是过度设计，那么您可能需要重新构建您的问题。问问自己，是否应该测试这段代码？

于 2013-03-28T16:12:59.937 回答
0

这里很难一概而论，但是加载程序集前后的评论表明该DoSomething方法可能违反了单一责任原则。也就是说，代码做了太多的事情。有很多方法可以编写代码，这样您就可以避免这种情况，您在问题中提到了其中两种。我想我会听从 Greg 的建议并在这里实施依赖注入。根据这个例子，我很难说什么是过度设计，什么不是过度设计。

于 2013-03-28T02:02:10.647 回答