Design patterns 我的方法应该去哪里

我有一个类，它表示表中的一行。我想添加一个函数来处理行中的数据。我应该在哪里添加函数

1） 类内部，因为它与类相关 2） 在类之外的一个单独的助手类中

在过去，我总是选第一。我开始认为数字2是一个更好的答案，因为它将逻辑分离到自己的封装类中，并降低了数据类的复杂性。我认为数据类应该尽可能地保持空，只包含绝对没有逻辑的数据成员

---

最灵活/最好的方法是什么？

这取决于您更喜欢“活动记录”还是“存储库”。我不确定是否真的有一个正确的答案，只是你的代码库中有什么意义。我也会考虑其他代码的设计，在设计这一点时，一致性和良好的设计一样重要。

< P>在纯MVC意义上，数字2是最好的选择。创建一个数据模型，使其不受所有实现逻辑的影响。这将允许您跨应用程序重用模型。然后，控制器可以容纳操作数据的特定于应用程序的实现逻辑。

取决于功能是什么。类的要点通常是封装函数和数据

如果函数特定于row类中保存的数据类型，并且row类是常规的，那么您可以从row类中创建子类并将函数粘贴到其中

helper类对于分解类的复杂性很有用，但是您应该确保helper与类的角色被明确定义，这样将来的维护就不会使契约变得混乱。

正确的答案是“这取决于”；“操纵行中的数据”可以证明这两种答案的合理性

在关注点分离方面，您需要确定此函数操作的抽象。它是数据库中一行的抽象吗？把它放在那节课上。是您的数据模型中以数据库中的一行实现的对象吗？把它放在那节课上

---

更一般地说，您应该将功能置于其应用的抽象级别，这在很大程度上取决于您的总体设计。

单一责任原则被表述为“对象更改的原因应该只有一个。”对于选项1，对象可能会更改的原因有两个：您可以更改对象中存储的数据，或者您可以更改为其他数据库系统（例如mySQL到PostgrSQL）

当然，就像所有事情一样，这是一种权衡。将所有代码放在一个地方有一些好处。如果将来不太可能切换到不同的RDBMS，那么将所有内容合并到一个类中可能是一个不错的选择

---

但是，如果您确实希望将来切换到不同的数据库，甚至支持多个数据库后端，那么最好将持久性放在单独的类中。

除非您正在开发一个可重用的框架，否则不要担心更改数据库系统。大多数应用程序永远不会改变数据库系统，因此，这通常是浪费的工作。当然，如果您正在开发一个其他人将在不可预见的环境中使用的可重用框架，那么是的，花时间来实现这个框架是有意义的。有时，您必须在您没有预料到的情况下（发生在我们身上）更改数据库系统。但是，只有在需要的时候，你才应该解决这个问题——如果你还不需要它，那么就不值得把复杂的事情处理掉。