如今，TDD 风靡一时，越来越多的软件商店正在转向敏捷、Scrum 等。我当然可以看到自动化测试的优势，但我也认为 TDD 与良好的面向对象设计的一些原则相矛盾。
TDD 要求您在代码中插入接缝，这些接缝通过接口(interface)公开实现细节。依赖注入(inject)或协作者注入(inject)违反了信息隐藏的原则。如果您的类使用协作者类，那么这些协作者的构造应该在类内部，而不是通过构造函数或接口(interface)公开。
我还没有看到任何文献解决编写可测试代码与同时坚持封装、简单和信息隐藏原则之间的冲突。是否以任何标准方式解决了这些问题？
最佳答案
你认为是实现细节的方法和类真的是接缝 表示您可以沿其 的轴改变和重组组件进入新的星座。
关于封装的经典思想往往过于粗粒度，因为 当你隐藏很多事件部件时，你也会使代码非常不灵活 .它也往往违反许多 SOLID原则 - 最突出的是 Single Responsibility Principle .
大多数面向对象的设计模式往往是相当细粒度的，并且非常符合 SOLID 原则，这是正确的面向对象设计是细粒度的另一个指标。
If your class uses collaborator classes then the construction of these collaborators should be internal to the class and not exposed through the constructor or interface.
这是两种不同的东西混合在一起。我同意在大多数情况下不应通过接口(interface)公开协作者。但是，通过构造函数公开它们是正确的做法。 Constructors are essentially implementation details of a class while the interfaces provide the real API .
如果你想保留一个粗粒度的 API 来定位默认功能，你仍然可以通过提供 Facade 来实现。 .有关详细信息，请参阅此帖子:Dependency Inject (DI) "friendly" library
关于unit-testing - 协调单元测试与 OOD，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5917601/