SRP：为什么使用实例字段值而不是参数？答案

【问题标题】：SRP: Why use instance field values instead of parameters?SRP：为什么使用实例字段值而不是参数？
【发布时间】：2010-12-20 15:59:37
【问题描述】：

我刚刚阅读了SRP, as easy as 123…，除了一段名为“凝聚力”的部分之外，所有这些都与我产生了共鸣（我之前曾声称要“获得”凝聚力，但这次谈论的是参数与实例字段让我停下来……）：

上课。看看你的方法。他们有参数还是他们使用实例字段？如果他们是使用参数，删除它们。制作它们是实例字段。你结束了吗使用仅使用其中一种的方法五个实例？这很可能是一个低凝聚力的警告该方法和您的之间存在类。

这种删除参数是否只是一种临时练习，以揭示接近静态能力（低内聚性）的方法，其想法是在完成后返回参数的使用？

或者优先考虑实例字段而不是参数是一种保持高内聚性的实际设计技术？

我是否以某种方式断章取义？

【问题讨论】：

实际上对我来说似乎很可疑。一些方法将有参数，不管你封装责任的程度如何。
奇怪的是，我会说相反，即：如果你看到一个类方法不使用任何类字段，而只使用参数，请将其提升为静态...
@dig，是的，这是标准 OO 与 FP 的区别。

标签： c# parameters instance-variables single-responsibility-principle cohesion

【解决方案1】：

CRUD 是一种真正常见的基于接口的编程方法。采用两个实现 CRUD 接口的具体类：Employee 和 Building。

现在想象一下您的代码基于参数的样子：

Employee employeeObj = new Employee();
Building buildingObj = new Building();

string firstName = "Bob";
employeeObj.Create(firstName);

建筑怎么样？

BuildingTypes buildingType = BuildingTypes.One;
building.Create(buildingType);

糟糕...你应该如何使用不同的参数实现 CRUD 接口？创建重载？更多接口？那么两个参数（名字姓氏）呢？

这将变得如此丑陋如此之快....因为一旦您将参数与 CRUD 接口一起使用，您就有不止一个理由进行更改，这会降低设计的凝聚力。

让我们尝试使用基于对象/实例的参数...

Employee empObj = new Employee();
empObj.FirstName = "Bob";

empObj.Create();

Building buildingObj = new Building();
buildingObj.BuildingType = BuildingTypes.One;

buildingObj.Create();

使用简单的 CRUD 并且没有参数，甚至可以添加多态性：

someObj.Create();

这也会导致封装组合、解耦、SRP 等...

【讨论】：