使用枚举更新工作项状态或创建更新工作项状态的特定方法答案

【问题标题】：Update work-item state using enum or create specific methods for updating work-item state使用枚举更新工作项状态或创建更新工作项状态的特定方法
【发布时间】：2021-06-09 21:02:39
【问题描述】：

声明：

有两种选择：

WorkItemState 是一个 emum，可以是：SCHEDULED、READY、SUBMITTED、EXECUTING、COMPLETED

创建单个方法：updateWorkItemState(workItemId, workItemState)
创建多个方法：markAsCompleted(workItemId)、markAsSubmitted(workItemId)、markAsExecuting(workItemId) 等。

在第一种方法中，我将工作项状态暴露给客户端，而在第二种方法中，我必须创建多个方法，即每个状态一个。

我还必须检查仅当当前状态有效时才能应用状态转换。 Ex- 如果工作项处于 EXECUTING 状态，则只有它可以完成。

这两种方法中哪一种在可读性、可维护性和可扩展性方面看起来更好？

【问题讨论】：

为什么不两者兼而有之？使第一个项目的 (1) 私有/受保护，然后使第二个 (2) 方法调用私有/受保护方法来处理实际工作。这对于可重用性和可读性是最好的。
是的。如果我采用第二种方法，我已经认为我会以这种方式编写代码，但问题是是否采用第二种方法。随着状态不断增加，方法也将开始增加。

标签： java c# oop design-patterns

【解决方案1】：

这是主观的，我更喜欢第二种方法。

第一种方法更通用，代码更少，易于编写和理解，并且只需要测试一个函数。我会说它违反了 S 的 SOLID 原则。每个状态都会要求您执行不同的任务，这很快就会变得复杂。测试用例虽然只有一个功能，但会有很多场景来测试一个功能。

第二种方法允许您为执行单个任务的消费者提供一个抽象方法。每种方法的代码都将简短而整洁。虽然它有更多的功能要测试，但它更容易更清楚地了解您要测试的内容。

此外，如果您想稍后更新其中一种状态的逻辑，您知道在哪里进行更改，并且不会破坏/重新测试其他任何内容。

无论如何，即使在第一个增长时，您最终也会将其划分为私有函数。最好为消费者提供简单的界面，而不是暴露你的状态。提供更大的灵活性。

【讨论】：

请告诉我你的想法，我们都在这个平台上一直在学习。