我有一个允许用户输入操作的应用程序（25 分钟时间段）。我正在使用 Ruby on Rails，但现在我只是想描述 Cucumber 的行为。
很长一段时间以来，我只允许用户在这个时间段内创建一个动作（动作总是必须在半小时开始）。
但是，现在我想添加计划的操作。唯一的区别是状态（不完整），它需要一个日期（计划在哪一天）而不是日期时间。然后，用户可以选择创建新的 NOW 操作或 PLANNED 操作（从当天可用的计划操作中选择）。
这是我需要创建新资源的情况吗？更一般地说，我如何知道是否需要添加新模型、新控制器或两者都不需要？
感谢您的帮助！
【问题讨论】：
标签： ruby-on-rails ruby rest architecture cucumber
很难将有关面向对象设计的所有内容都放在一篇文章中，但我可以尝试。
很久以前是这样向我解释的：
类都是关于行为的。每次添加一些愚蠢的字段时，您都无法定义新的类或子类。你应该以懒惰和常识为指导（主要是）。所以，如果你告诉我 Sun 是 Circle 的子类……我不想生活在这样的世界里。
基本上，您需要根据模型的行为来考虑模型。在 Rails 中，他们关注active record pattern。它们结合了数据存储和业务逻辑的特性。因此，如果计划行动和简单行动之间存在很大差异（不是在数据方面，而是在不同的行为方式、处理方式等方面），您需要一个新的模型来解决这个问题。
控制器本身从资源到资源都非常相似，我们中的一些人使用像 Inherited Resources 这样的 gem 来编写更少的代码。通常，您的应用程序中的每种资源都有一个控制器。
我希望它能回答你的问题。至少有一点。
更新。
让我们围绕您的示例跳舞（操作/计划的操作）。
您添加了status 字段并将datetime 替换为date（实际上几乎没有任何变化）。因此，您很可能添加了一个新特征 - status 字段并跟踪操作的当前状态。我相信会有一些逻辑来启动这些行动，跟随他们的进展或其他事情。 可以开始、停止和跟踪的动作的这一方面与简单的Action 的特征完全不同。即使是一个函数，一个行为的方面就足够了，可以将该功能提取到一个单独的类中。
您可以将对象视为现实世界中对象的投影。 Action 是一个抽象概念，您已经选择了它的一些特征来呈现在您的应用程序中（忽略其他所有内容）。
当您介绍PlannedAction 时，您需要考虑您希望它具有的特征。 PlannedAction 在某些情况下是否可以只是一个Action（例如，您需要显示给定日期的所有操作的某种时间表）？
如果您发现在某些情况下PlannedAction 需要替代Action，则需要从Action 继承PlannedAction。基类永远不会知道status 字段和类似的所有内容，但会为PlannedAction 提供基本功能。
但是，如果PlannedAction 与简单的Action 差别太大（不同的用例和行为），您可能会考虑将PlannedAction 设为一个单独的类，完全没有继承。
在无数次尝试和失败之后，您会发现自己感觉，例如，Car 与MetalSlug 相差甚远，不应该继承它。但是Car 与Truck 相差不远，他们可能有一个共同的父级 - Vehicle。
【讨论】：