Nella programmazione orientata agli oggetti quale oggetto dovrebbe mantenere la relazione molti a molti? (Se ce n'è uno)

Question

userò un esempio per illustrare questo:

class Company { 

} 

class Person { 

} 

Company e Person in possesso di un rapporto molti a molti. Un Person può appartenere a più Companies e un Company può contenere più People.

Avrei quindi bisogno di creare una terza classe:

class CompanyPerson { 

} 

o qualora la società gestirlo:

class Company { 
    function add_person() { 

    } 
} 

o forse la Person dovrebbe?

class Person { 
    function add_to_company() { 

    } 
} 

Answer 1

Le proprietà comuni a una combinazione casuale di un'istanza Person e Company possono essere modellati utilizzando una "classe di associazione".

C'è una notazione per questo in UML e non è difficile creare un tale concetto in un linguaggio di programmazione estendibile.

L'idea è che qualsiasi coppia casuale di oggetti costituita da un Person e da Company abbia una relazione e che la relazione sia essa stessa un oggetto. Non è né Person né Company, ma i materiali associati alla connessione tra una particolare istanza Person e Company.

Quella roba (proprietà, metodi) costituisce una classe: la classe di associazione Person-Company.

Ho fatto questo lavoro in Lisp prima, con alcune macro per definire una classe di associazione per una data coppia di classi, e una tabella hash globale debole per il mapping delle coppie di oggetti al loro oggetto di classe di associazione (in modo che per una determinata persona e è stato possibile recuperare l'associazione e quell'associazione andrebbe via quando questi oggetti diventeranno spazzatura).

Il collegamento effettivo tra determinate aziende e persone è semplice, utilizzando ad es. liste o altre strutture dati associative. Un oggetto persona può avere un elenco di società e viceversa. L'idea della classe di associazione affronta il problema di dove mettere le cose della persona-azienda. Ad esempio, ogni Person ha un ruolo all'interno di un Company (diciamo). Non è possibile avere una variabile role in un Person perché può avere molti ruoli con molte aziende. Di certo non possiamo avere un role nella compagnia perché non è nemmeno una persona; ha persone ad esso associate che hanno ruoli. Il ruolo può entrare nell'associazione: problema risolto.

Answer 2

Dipende totalmente dallo scenario di utilizzo.

Se si ha sempre bisogno di trovare le persone che lavorano per un'azienda, memorizzare l'elenco di Persone sulla Società; se hai sempre bisogno di trovare le aziende per le quali le persone lavorano, allora memorizzale lì.

Prima o poi probabilmente troverai la necessità di modellare il rapporto reale Persona < -> Società e dovrai creare una classe separata per rappresentarlo. Ora puoi gestire l'aggiunta di proprietà come la data di inizio dell'impiego, la data di fine, ecc.

Answer 3

Beh, non penso che tu abbia bisogno di una terza classe.

pensare a quello che un ORM (Doctrin per PHP, hybernate forn java) fa:

In questo caso su un layer databse avrete 3 tabelle:

Società, Utente e Company_user (join tabella beetween utente e azienda che dice quale utente si adatta a quale società).

Inoltre è possibile mappare questa situazione solo con due tavoli DB:

Società, degli utenti e in utente si dispone di una punta di riferimento a società. In base a questo riferimento, puoi dire la società a cui appartiene l'utente.

Infine su un design di classe penso:

• Classe companuy può contenere una serie di utenti (elenco di utenti appartenenti alla società)
• utente Class può contenere un riferimento alla società (la società del bleongs utente a)

Answer 4

Questo dipende dal caso d'uso, ma generalmente molti a molti oggetti possono essere implementate utilizzando una classe di riferimento

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

Così ora, sia società e persona può tiene traccia della loro menzogna rapporto

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

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