OOP中的单一责任原则

Question

在我的应用程序设计中，我通常将对象映射到数据库中的重要表。然后，对象处理与该数据相关的所有内容（包括链接表）。例如，我建立了一个Activity对象，其中包含name和due_date等属性，load()和save()等方法，以及{{1}等方法}，getParent()和getContributors()，它们返回（数组）其他对象。这是“坏”的OOP，因为它违反了单一责任原则吗？

Answer 1

这取决于具体情况和您拥有的确切代码：您的设计可能会触及多个职责，并且仍然是一个非常好的OOP并且可维护。

您是否使用类似代码处理每个班级中的load()和save()？或者将load()和save()中的任务委托到几个类中用于此功能的其他对象？这将是继SRP之后的一半，仍然是根据您的设计。

如果没有，你的代码真的有点臭。要检查它是否涵盖多项职责，请问自己：什么可能导致我的班级发生变化？在您的情况下，我至少会尝试重构 {{ 1}}和load()在不同的类中达到上述情况，以便

• 可维护性大大提高，
• 您仍然无需更改客户的代码。

Answer 2

嗯......现阶段很难说清楚。你可以把整个课程打包过来，但是......

是的，它看起来像是糟糕的OOP。您有相同的类负责与数据库和域逻辑的交互。这会产生两个完全不同的原因，即改变类。

您可以通过探索DataMapper模式获益。

Answer 3

也许我会因此而陷入困境（因为我不是专家）但是：

域对象中的方法load（）和save（）称为Active Record（Another description）。这还不错（尽管我不喜欢它），因为那些可能会在你之后或与你一起工作的人在找出如何坚持这些物体时会遇到更少的问题。

关于其他方法。如果它在对象域中并且它代表对象行为，那就不那么糟糕了。如果设计得很好，它可以非常好。 Domain driven design鼓励使用与贫血领域模型相反的富域模型。 anemic domain model具有仅具有属性和getter以及setter的域对象。因此，只要它在您的对象的域中，在其中添加其他方法就不会被认为是错误的。

据我所知，这是我所阅读的书籍和文章中的概念。

希望有所帮助......

Answer 4

您所描述的是ActiveRecord，众所周知它违反了SRP。此外，ActiveRecord仅在表行与对象紧密匹配时才能正常工作。一旦Impedance Mismatch变得太大，它将在以后更难以对系统进行更改。

它不一定是糟糕的OOP，但它是Technical Debt的一种形式，因为持久性逻辑和域逻辑之间缺乏分离。违反任何SOLID原则通常会导致难以更改代码，脆弱的代码，不可重用的代码。

其中一些债务不是问题。这些债务累积了利息，例如当他们开始涉及其他设计决策时。换句话说，当您注意到更改系统变得更加困难时，请尝试偿还一些债务，例如：重构一个更易维护的解决方案。

Answer 5

我认为重要的是不要认为模型应该只是逻辑和数据库之间的层。模型可以与数据库一起使用，与其他模型一起使用，所有逻辑都应该在模型中 我认为有两种方式：

1. 您的模型可以在getContributors()方法中返回ID数组，您可以创建新对象（可能是Factory），它会将这些ID转换为对象。
2. 您的模型可以返回对象数组，但不使用new关键字，而是通过Factory或Dependencies容器（我更喜欢DC）。