在我的应用程序设计中，我通常将对象映射到数据库中的重要表。然后对象处理与该数据相关的所有内容（包括链接表）。例如，我构建了一个Activity 对象，具有name 和due_date 等属性，load() 和save() 等方法，以及getParent()、getContributors() 和getTeam() 等方法返回（数组）其他对象。这是因为它违反了单一职责原则，所以这是“坏”的 OOP 吗？
【问题讨论】：
标签： php oop single-responsibility-principle
这取决于情况和您拥有的确切代码：您的设计可能涉及多个职责，但仍然是一个非常好的 OOP 且可维护。
您是否使用相似代码在每个类中处理load() 和save()？或者您是否将load() 和save() 中的任务委派 给在多个类中用于此功能的其他对象？这将是 SRP 之后的一半，但仍符合您的设计。
如果没有，您的代码确实看起来有点臭。要检查它是否涵盖多个职责，请问问自己：什么可能导致我的课程发生变化？在您的情况下，我至少会尝试重构 @987654325 中的类似代码@和save()在不同的类中达到上述情况，这样
【讨论】：
load() 和save() 的代码重用是一个很好且重要的主题，但对于另一个问题。模型可以根据需要与 DB 一起使用 - 使用代码重用（ORM、Mapper）或不使用 - 取决于具体情况下哪个更好。在这个问题中，我认为主题是与其他模型、依赖项和责任合作。
load() 方法中，我只运行（特定于类的）查询来获取数据，进行一些预处理，例如在name 等文本属性中转义HTML 字符，并将数据分配给对象的属性。
嗯..在这个阶段很难说。你可以把整个班级都过去，但是..
是的，它看起来像糟糕的 OOP。您有同一个类负责与数据库和域逻辑的交互。这就产生了两个完全不同的类改变的原因。
您可能会从探索DataMapper 模式中受益。
【讨论】：
也许我会在黑暗中踢这个（因为我不是专家）但是：
域对象中的方法 load() 和 save() 称为 Active Record (Another description)。这还不错（尽管我不喜欢它），因为可能会在您之后或与您一起工作的人在弄清楚如何持久化这些对象方面会遇到更少的问题。
关于其他方法。如果它在对象域中并代表对象行为，那还不错。如果设计得好，它可能会非常好。 Domain driven design 鼓励使用与贫血域模型相反的富域模型。 anemic domain model 的域对象只有属性、getter 和 setter。因此，只要它在您的对象的域中，在其中添加其他方法就不会被认为是坏事。
这是我从我读过的书籍和文章中理解的那些概念..
希望对你有帮助。
【讨论】：
您描述的是 ActiveRecord，众所周知它违反了 SRP。此外，ActiveRecord 仅在表行与对象紧密匹配时才能正常工作。一旦阻抗失配变得太大，以后对系统进行更改就会变得更加困难。
这不一定是糟糕的 OOP，但它是Technical Debt 的一种形式，因为持久性逻辑和域逻辑之间缺乏分离。违反任何 SOLID 原则通常会导致代码难以更改、代码脆弱、代码不可重用。
其中一些债务不是问题。当这些债务累积利息时，例如当他们开始影响其他设计决策时。换句话说，当您发现更改系统变得更加困难时，请尝试偿还一些债务，例如重构为更可维护的解决方案。
【讨论】：
我认为不要再认为模型应该只是逻辑和数据库之间的层，这一点很重要。模型可以与数据库和其他模型一起使用，所有逻辑都应该在模型中。
我认为有两种方法：
getContributors() 方法中返回 ID 数组，并且您可以创建新对象（可能是工厂），它将这些 ID 转换为对象。new 关键字，而是通过工厂或依赖项容器（我更喜欢 DC）。【讨论】：