我是性能的真正爱好者,但我也意识到执行自动化测试的重要性(直到更好的形式验证方法成为主流)。
缺点是,当您尝试设计可测试性时,您开始引入接口(interface)来表示依赖项。如您所知,接口(interface)使您的调用可以通过该依赖项动态分派(dispatch),并减少编译时的优化机会。
class MyDependency
{
void someMethod();
}
class MyUnit
{
// Concrete type reference of MyDependency allows
// to bypass the dynamic dispatch
this(MyDependency mayBeAMock)
{
mayBeAMock.someMethod();
}
unittest
{
// Now how can I get a mock of my dependency without to instantiate it.
auto dep = someBlackMagic.getMock();
auto uut = new MyUnit(dep);
}
}
确实存在一种更好的方法来对类进行单元测试,而无需在生产中考虑动态调度成本。如果需要,我可以承担单元测试执行的成本,但不能承担生产版本的成本。
我对 D 和 C++ 解决方案感兴趣。
最佳答案
我在 D 中经常使用的一项技术是进行编译时策略替换:
private struct MyUtilImpl ( HTTPClient )
{
void foo ( )
{
HTTPClient.makeRequest("url");
}
}
version (unittest)
alias MyUtil = MyUtilImpl!FakeHTTPClient;
else
alias MyUtil = MyUtilImpl!RealHTTPClient;
它在精神上与经典的依赖注入(inject)非常相似,但我没有模拟 I/O 实用程序并通过接口(interface)进行交换,而是使用模板参数在编译时执行相同的操作。
它还有一个好处是不需要更改程序其余部分的任何内容即可开始传递接口(interface)。
关于C++ 或 D : idiom to decouple classes without dynamic dispatch?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37088958/