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