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