W Object Oriented Programming, który obiekt powinien utrzymywać relacje wiele do wielu? (Jeśli istnieje)

Question

Użyję przykład ilustrujący to:

class Company { 

} 

class Person { 

} 

Company i Person posiadać wiele do wielu relacji. Numer Person może należeć do wielu,i może pomieścić wiele osób.

Chciałbym następnie należy utworzyć trzecią klasę:

class CompanyPerson { 

} 

lub firma powinna poradzić:

class Company { 
    function add_person() { 

    } 
} 

czy może Person powinien?

class Person { 
    function add_to_company() { 

    } 
} 

Answer 1

Właściwości wspólne dla niektórych losowo kombinacji Person i Company przykład może być modelowany za pomocą „klasy asocjacji”.

Jest to zapis w UML i nie jest trudno stworzyć taką koncepcję w rozszerzalnym języku programowania.

Chodzi o to, że dowolna przypadkowa para obiektów składających się z Person i Company ma związek, a ta relacja sama w sobie jest obiektem. Nie jest to ani Person ani Company, ale rzeczy związane z połączeniem między konkretną instancją Person i Company.

Te rzeczy (właściwości, metody) stanowią klasę: klasa stowarzyszenia Person-Company.

Zrobiłem tę pracę w Lisp wcześniej, z niektórymi makrami do definiowania klasy asocjacyjnej dla danej pary klas oraz globalną tabelą skrótów dla odwzorowywania par obiektów do ich obiektu klasy asocjacyjnej (tak, że dla danej osoby i firma mogła odzyskać skojarzenie, a to skojarzenie zniknęłoby, gdy te obiekty staną się śmieciami).

Rzeczywiste połączenie między poszczególnymi firmami i ludźmi jest łatwe, np. listy lub inne asocjacyjne struktury danych. Obiekt osoby może mieć listę firm i odwrotnie. Idea klasy stowarzyszeniowej rozwiązuje problem polegający na tym, gdzie umieścić rzeczy osoby i firmy. Na przykład każdy Person ma rolę w Company (powiedzmy). Nie możemy mieć zmiennej role w Person, ponieważ może ona mieć wiele ról w wielu firmach. Z pewnością nie możemy mieć w firmie role, ponieważ nie jest to nawet osoba; ludzie mają z nim związane role. Rola może zostać włączona do stowarzyszenia: problem rozwiązany.

Answer 2

To całkowicie zależy od scenariusza użycia.

Jeśli musisz tylko znaleźć ludzi, którzy pracują dla firmy, zapisz listę osób w firmie; jeśli potrzebujesz tylko znaleźć firmy, w których pracują ludzie, zapisz go tam.

Prędzej czy później prawdopodobnie okaże się, że musisz modelować rzeczywisty związek Osoba < -> Firma i utworzysz oddzielną klasę do reprezentowania tego. Teraz możesz obsłużyć dodawanie nieruchomości, takich jak data rozpoczęcia zatrudnienia, data jego zakończenia itd.

Answer 3

Cóż, nie sądzę, że potrzebujesz trzeciej klasy.

myśleć, co ORM (Doctrin dla PHP, Hybernate Forn Java) ma:

W tym przypadku na warstwie databse będziesz mieć 3 tabele:

firmą Dokumentacja Company_user (dołączyć tabelę beetween użytkownik i firma, która mówi, który użytkownik należy do której firmy).

Również można odwzorować tę sytuację tylko z dwóch tabel DB:

Spółki, użytkownik i użytkownik masz wskazując odniesienia do firmy. Opierając się na tej referencji, możesz powiedzieć, do której firmy należy użytkownik.

Wreszcie nad projektem klasy myślę:

• Klasa companuy może posiadać tablicę użytkownika (listy należących do firmy użytkownika)
• Klasa użytkownik może posiadać odniesienie do spółki (firmie bleongs użytkownika do)

Answer 4

to zależne od przypadku zastosowania, ale zwykle wielu wielu relacji obiektu może być wdrożony za pomocą punktów odniesienia

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

Więc teraz, zarówno firma i osoba może śledzi ich związek kłamstwa

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

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