srp unity_没有SRP？ 没有TDD！

srp unity

我一直在思考是什么使TDD失败，并且显然没有几个被讨论到死的原因（明白吗？死了吗？TDD？好吧，让我们继续前进）。

与初学者一起工作时，我会看到一种模式。 我说的是TDD初学者，因为这些人可能对他们有多年的经验。 他们虔诚地遵循红绿色步骤，并在此过程中进行最少的重构。

通常，重构看起来像这样：

• 当然，重命名非常重要。
• 将代码提取到私有方法中。
• 切换控制流是新增设计的一部分。 例如，添加循环，将if-else替换为开关盒。
• 对数据结构进行小的修改，尽管不是很多。

这给您带来的是一个大型的，复杂的类，该类具有测试以及一些小的内部简单数据类。

测试很好。 但这是那些TDD狂热者经常谈论的神奇的紧急设计吗？

坚实的地面

在SOLID的五项原则中 ，单一责任原则对TDD的影响最大。 尽管SOLID原理是通用的（我听说它们在半人马座上非常重要），但TDD的由外而内的方法将S与其他方法分开。

OLID原则主要与外部接口有关。

• 开放/封闭原则：通常在OO中转换为针对接口/基类的工作
• Liskov的Substitution原则内置于OO语言中。 我们认为基类和子类通过最强大的接口表现为相似的行为。
• 接口隔离与接口有关。
• 依赖注入与可测试性以及接口有关。

Liskov的Substitution原则与其他原则有些不同，因为替换不仅涉及界面，还涉及行为。 行为表示内部代码。

虽然L原则对内部实施的影响很小，但SRP主要是针对它。 SRP是关于回答重要的设计问题：

该代码应放在哪里？

此代码应使用私有方法吗？

是否应该将其提取到另一类？

是否应该将其分为基类和派生类？

它应该被称为虚拟方法，而不是基础方法吗？

是否应该单独测试？

该代码应该去哪里？

重构的很大一部分是乏味地问这个问题。 当我们这样做时，就会出现更简单的设计。 代码移入较小的类和组件，移入较小的方法，然后将私有方法提取到其他类，这些类更有意义（且命名更好）。

所得的代码与上面所述的代码截然不同。 这可能会成败TDD实现。

TDD误导

看起来只要遵循红绿重构，就可以为您提供正确的设计。

这是一个谎言。

如果您相信这一点，就会陷入“ TDD已死”的人群。

TDD的“紧急设计”部分并非来自键盘。 您和我推动设计。

创建可读性，可理解性和可维护性设计的最佳方法是询问“此代码应该去哪里”。

这就是SRP的力量。 如果您不了解TDD就陷入困境，那么您很可能会失败。

翻译自: https://www.javacodegeeks.com/2014/06/no-srp-no-tdd.html

srp unity