可测性与过度设计？

这里的情况实际上是由一个同事是挂了我的兴趣提出：可测性与过度设计？

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类似，但我想深入挖掘它。

来源

2013-03-27 Justin Pihony

难道你不能实现*依赖注入*？如果以这种方式构建它，它将保持可测试和可维护。虽然它会稍微难以阅读。 – Greg 2013-03-27 18:34:17

更好的问题是，你在构造函数中放置了多少逻辑？如果你需要单元测试你的构造函数，听起来更像是一种代码味道给我。 – 2013-03-27 18:36:49

为第二个选项投票。它确实造成了开销，但它并不是很大，而且它提供了一个“更大的目的”。它干净而且易于理解，并且使用自动注册的DI容器，在单元测试之外，您甚至不必关心它。 – TeaDrivenDev 2013-03-27 18:46:19

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

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

当您需要在不受控制的代码上配置状态时，为第三方服务创建包装通常是智能的。它没有你想象的那么糟糕。事实上，我看不到另一种方式来做到这一点。无论你如何分割它，无论你是在嘲笑一些第三方库，使用一些反思魔术，还是使用你的特定解决方案，它都归结为真正的第三方API。

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

来源

2013-03-28 16:12:59

嗯，我同意。我想这个问题来自事实，我通常不会嘲笑一种静态方法。但是，此方法对文件系统具有外部依赖性。真正的问题是，这可能应该是一个实例对象，这就是问题所在......为了可测试性，我必须包装某些东西，这就是为什么我不喜欢它。它只是为了可测试性而改变我的代码，但这只是由于第三方的糟糕设计造成的...... – 2013-03-28 17:29:25

@JustinPihony“但这只是由于第三方的糟糕设计”。是的，这正是你想从中抽象出来的东西。为了测试能力而改变代码不是一件坏事。如果你关心测试，改变代码来支持它只是让你的代码在你的需求中“更加正确”。 – 2013-03-28 18:29:00

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

来源

2013-03-28 02:02:10 bcarlso

可测性与过度设计？

回答

相关问题