单一责任原则是不是促进了逻辑分组之上的许多小类？

Posted 2023-03-15

【中文标题】单一责任原则是不是促进了逻辑分组之上的许多小类？

【英文标题】：Does the single responsibility principle promote many small classes over a logical grouping?单一责任原则是否促进了逻辑分组之上的许多小类？

【发布时间】：2015-01-28 15:57:08

【问题描述】：

我了解基本概念，并且每个示例都显示了两个完全不同的问题来说明这一点，但我的问题是关于相关但独立的问题。

拿一个简单的计算器。它有以下4种方法：

添加 减法 相乘 除法

我认为大多数开发人员会创建一个包含 4 个方法的类。但这会破坏 SRP 对吗？这是否应该分为 4 个单独的类，每个操作一个类？

也许是的，因为假设我们对每个方法都有重载。如果我们想对 int、float 和 decimal 执行操作，我们的方法列表会扩展到 12 个。所以也许单独的类会更好。这更有意义（将它们分成 4 个类），但是当没有重载且只有 4 个方法时，您应该这样做吗？

让我们添加更多方法：

罪 cos 谭

您是否将这 3 种方法添加到上述 4 种方法中？您是否为每个班级创建一个单独的班级？您是否将上述 4 个分组为 Basic 类，而将这 3 个分组为 Geometry 类？

【参考方案1】：

与所有设计一样 - “视情况而定”。

如果您只是编写一个简单的计算器，对整数进行加、减、乘和删除，请务必将它们设为方法。

但是，正如您正确指出的那样，当您开始添加其他操作时，它会使 Calculator 类膨胀。如果您支持浮点或 BigDecimal 类型的数据，那就更糟了。

一个好的设计可能是有一个Operation 接口：

interface Operation<T>
  T apply(T a, T b);

然后像Add、Sin 等每个操作都将是实现该操作接口的类（或枚举，如果您的语言提供的话）。模板类型将允许添加整数、添加浮点数、添加 BigDecimal 等。

这也让其他人提供自己的操作（或优化的操作版本）

虽然可能值得考虑只实现 BigDecimal 版本并将整数和浮点数转换为 BigDecimal。

【参考方案2】：

取决于您如何看待职责。 从现在开始，我将不再使用“计算”​​，而是使用“计算”​​来描述数学运算的结果（计算可以有更广泛的含义）。

计算器的唯一职责是“计算”。对外界来说，引擎盖下的东西是魔法，但计算器只能计算。

在实现方面，如何实现“计算”是您的选择（多个计算类、输入解释器、函数等）。

因此，无论您的计算器如何实现，都将遵守单一职责原则。

如果你的计算器，你将打破原则，除了“计算”还可以拍照和生火。

现在我们已经确定了计算器的职责，让我们进一步放大，看看我们是否可以在计算器的实现中定义一些 SRP。

假设您决定让您的计算器可扩展，而不是为每个可能的计算创建一个包含 1 个函数的巨大类，并且您可以添加不同的对象来计算不同的数学函数。

每个对象都有一个单一的责任原则，即计算一个，并且只有一个，数学表达式。

所以，下面的类：

添加 除法 减去（即 Add btw ） 相乘 谭 cos

将匹配我们定义的 SRP，只要它们不进行超过一次的计算。

如果我们改为添加函数

在 x 和 y 之间进行棕褐色和绘图

SRP 计算将被破坏，因为您将拥有：

计算 间隔内的离散增量 情节