9

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

4

5 回答 5

5

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

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

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

  • 可维护性大大提高，
  • 您仍然不需要更改客户的代码。
于 2011-09-14T08:37:21.547 回答
1

嗯..在这个阶段很难说。你可以把整个班级都过去，但是..

是的，它看起来像糟糕的 OOP。您有同一个类负责与数据库和域逻辑的交互。这为阶级改变创造了两个完全不同的原因。

您可能会从探索DataMapper模式中受益。

于 2011-09-14T08:38:07.873 回答
1

也许我会在黑暗中踢这个（因为我不是专家）但是：

域对象中的 load() 和 save() 方法称为Active Record（另一种描述）。这还不错（尽管我不喜欢它），因为可能会在您之后或与您一起工作的人在弄清楚如何持久化这些对象方面会遇到更少的问题。

关于其他方法。如果它在对象域中并代表对象行为，那还不错。如果设计得好，它可能会非常好。领域驱动设计鼓励使用与贫血领域模型相反的丰富领域模型。贫血的域模型具有仅具有属性以及 getter 和 setter 的域对象。因此，只要它在您的对象的域中，在其中添加其他方法就不会被认为是坏事。

这是据我从我读过的书籍和文章中理解的那些概念..

希望能帮助到你..

于 2011-09-14T08:47:07.530 回答
1

你描述的是一个 ActiveRecord，众所周知它违反了 SRP。此外，ActiveRecord 仅在表行与对象紧密匹配时才能正常工作。一旦阻抗失配变得太大，以后对系统进行更改就会变得更加困难。

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

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

于 2011-09-14T11:49:29.690 回答
0

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

  1. 您的模型可以在getContributors()方法中返回 ID 数组，并且您可以创建新对象（可能是工厂），它将这些 ID 转换为对象。
  2. 您的模型可以返回对象数组，但不使用new关键字，而是通过工厂或依赖项容器（我更喜欢 DC）。
于 2011-09-14T08:50:04.483 回答