unit-testing - 函数式编程、SRP、可测试性和具有静态和实例可变字段的类

Question

我希望我能正确地表达这个问题。在处理具有静态和实例可变字段的类中的状态和可测试性时，我有一个担忧。

由于生命周期/范围的不同，静态字段是否本质上构成了不同的类/职责/实例？

如果是这样：那么实例字段不应该也是一个单独的类/数据结构吗？

然后：如果是这样，那么不应该所有类都是无状态的，只接收它们对构造的依赖，然后都应该是不可变的吗？

最后，这是否意味着函数式编程也是进行面向对象编程的正确方法？

Answer 1

你不应该有（真的）可变的静态字段。那是蹩脚的设计。函数式编程使事情变得容易得多。我会把这些问题分开：

• 什么是数据，应该只有在课堂上操作它的必要代码。像 "string" "Integer" "Person" ，这些是实体
• 什么操作数据，取决于数据，但不应该有内部状态（格式化程序等）
• 什么驱动执行，通常必须有一些内部状态，但它要么随调用携带，要么是“配置”，如数据库连接、请求等。这要么来自活动请求，要么是纯配置（注入）
• 什么视图结果（纯视图）本身应该是无状态的，状态应该通过上下文提供给它
• 然后中间有胶水，通常是毛茸茸的例外……尽量减少。

ETC..

为了可测试性

• 数据应该可以模拟到假数据库。
• “什么操纵数据”应该很容易测试，因为它是无状态的。
• 包含在上下文中的状态很容易模拟。
• “什么驱动执行”应该很容易测试，因为依赖项是可注入的，你可以逐个测试它。
• 视图很容易测试，因为可以将模拟状态提供给它。困难来自实际验证“它看起来像什么”，但这取决于 gui 自动化或人工测试人员。

本质上，如果数据库（磁盘）和请求层（web、ui 等）符合要求，所有这些都可以以功能方式完成。在实践中，您尝试在 pretty 和 functionalish 之间做“纯粹”的部分，并使用设计模式来保护它免受外部污垢的影响。