我会用一个例子来说明这一点：
class Company {
}
class Person {
}
Company 和 Person 保持多对多关系。一个Person 可以属于多个Companies，一个Company 可以包含多个People。
然后我需要创建第三个类吗：
class CompanyPerson {
}
或者公司应该处理它：
class Company {
function add_person() {
}
}
或者Person 应该？
class Person {
function add_to_company() {
}
}
【问题讨论】：
标签： php oop class many-to-many
这完全取决于您的使用场景。
如果您只需要查找为公司工作的人员，请将人员列表存储在公司中；如果您只需要找到人们工作的公司，然后将其存储在那里。
迟早您可能会发现您需要对实际的关系 PersonCompany 进行建模，并且您将创建一个单独的类来表示它。现在您可以处理添加属性，例如雇佣开始的日期、结束的日期等。
【讨论】：
Person 和Company 实例的某些随机组合共有的属性可以使用“关联类”建模。
在 UML 中有一个表示法，在可扩展的编程语言中创建这样的概念并不难。
这个想法是任何由Person 和Company 组成的随机对象对都具有关系，并且该关系本身就是一个对象。它既不是Person 也不是Company，而是与特定Person 和Company 实例之间的连接相关的东西。
这些东西（属性、方法）构成一个类：Person-Company 关联类。
我之前在 Lisp 中做过这项工作，使用一些宏来为给定的一对类定义一个关联类，以及一个用于将对象对映射到它们的关联类对象的全局弱哈希表（这样对于给定的个人和公司可以检索关联，并且当这些对象变成垃圾时，该关联就会消失）。
特定公司和人员之间的实际联系很容易，例如使用列表或其他关联数据结构。一个人对象可以有一个公司列表，反之亦然。关联类的想法解决了将人与公司的东西放在哪里的问题。例如，每个Person 在Company 中都有一个角色（假设）。我们不能在 Person 中包含 role 变量，因为它可以在许多公司中扮演许多角色。我们当然不能在公司中有role，因为它甚至不是一个人；它有与之相关的具有角色的人。角色可以进入关联：问题已解决。
【讨论】：
嗯，我认为你不需要第三节课。
想想 ORM（Doctrin for php，Hybernate forn java）做了什么：
在这种情况下，在数据库层上，您将有 3 个表：
Company、User 和 Company_user（连接用户和公司之间的表，说明哪个用户属于哪个公司）。
您也可以只使用两个数据库表来映射这种情况：
Company, user 和 in user 你有一个指向公司的引用。所以根据这个参考你可以说用户所属的公司。
最后是我认为的类设计：
【讨论】：
这取决于用例，但通常可以使用引用类部署多对多对象关系
class CompanyPersonRelationship {
public $company;
public $person;
}
所以现在，公司和个人都可以跟踪他们的关系谎言
class Company {
public $persons = array();
}
class Person {
public $companies = array();
}
【讨论】：