В объектно-ориентированном программировании какой объект должен поддерживать связь «многие ко многим»?(если есть)

Question

Я буду использовать пример, чтобы проиллюстрировать это:

class Company {

}

class Person {

}

Company и Person поддерживают отношения многие ко многим. Person может принадлежать нескольким Companies, а Company может содержать несколько People.

Тогда мне нужно создать третий класс:

class CompanyPerson {

}

или если компания справится с этим:

class Company {
    function add_person() {

    }
}

или может Person должен?

class Person {
    function add_to_company() {

    }
}

Answer 1

Это полностью зависит от вашего сценария использования.

Если вам нужно только найти людей, которые работают в компании, сохраните список людей в компании; если вам когда-нибудь понадобится найти компании, в которых работают люди, храните их там.

Рано или поздно вы, вероятно, обнаружите, что вам нужно смоделировать фактические отношения Person <-> Company, и вы создадите отдельный класс для представления этого. Теперь вы можете обрабатывать добавление свойств, таких как дата начала работы, дата окончания и т. Д.

Answer 2

Свойства, общие для некоторой случайной комбинации экземпляра Person и Company, могут быть смоделированы с использованием «класса ассоциации».

Для этого есть обозначение в UML, и это не сложносоздать такую ​​концепцию в расширяемом языке программирования.

Идея состоит в том, что любая случайная пара объектов, состоящая из Person и Company, имеет отношение, и это отношение само является объектом.Это не Person и Company, но материал, связанный со связью между конкретным Person и Company экземпляром.

Этот материал (свойства, методы) составляет класс: Person-Company ассоциативный класс.

Я делал эту работу в Лиспе раньше, с некоторыми макросами для определения класса ассоциации для данной пары классов и глобальной слабой хэш-таблицей для отображения пар объектов в их объект класса ассоциации (такчто для данного человека и компании было возможно получить ассоциацию, и эта ассоциация исчезнет, ​​когда эти объекты станут мусором).

Реальная связь между отдельными компаниями и людьми проста, например, с помощью списков или других ассоциативных структур данных.Объект-человек может иметь список компаний, и наоборот.Идея ассоциативного класса решает проблему размещения персонала компании.Например, каждый Person играет роль в Company (скажем).Мы не можем иметь переменную role в Person, потому что она может иметь много ролей во многих компаниях.У нас, конечно, не может быть role в компании, потому что это даже не человек;с ним связаны люди, у которых есть роли.Роль может перейти в ассоциацию: проблема решена.

Answer 3

Это зависит от варианта использования, но, как правило, отношения между многими объектами могут быть развернуты с использованием ссылочного класса

class CompanyPersonRelationship {
    public $company;
    public $person;
}

Так что теперь и компания, и лицо могут отслеживать свои отношения ложь

class Company {
   public $persons = array();   
}

class Person {
   public $companies = array();
}

Answer 4

Ну, я не думаю, что вам нужен третий класс.

Подумайте, что делает ORM (Doctrin для php, Hybernate forn java):

В этом случае на слое базы данныху вас будет 3 таблицы:

Company, User и Company_user (объедините таблицу между пользователем и компанией, которая говорит, какой пользователь принадлежит какой компании).

Также вы можете сопоставить эту ситуацию только с двумя дБ.таблицы:

Компания, пользователь и пользователь, у вас есть ссылка, указывающая на компанию.Таким образом, основываясь на этой ссылке, вы можете сказать, к какой компании принадлежит пользователь.

Наконец, по поводу дизайна класса я думаю:

• Класс компании может содержать массив пользователя (список пользователейпринадлежащий компании)
• Пользователь класса может содержать ссылку на компанию (компанию, к которой относится пользователь)