En Programación Orientada a Objetos, ¿qué objeto debe mantener la relación de muchos a muchos? (Si hay uno)

Question

voy a utilizar un ejemplo para ilustrar esto:

class Company { 

} 

class Person { 

} 

Company y Person mantenga una relación muchos a muchos. Un Person puede pertenecer a múltiples Companies y un Company puede contener múltiples People.

¿Me continuación, tendrá que crear una tercera clase:

class CompanyPerson { 

} 

o debería la empresa manejarlo:

class Company { 
    function add_person() { 

    } 
} 

o tal vez el Person debe?

class Person { 
    function add_to_company() { 

    } 
} 

Answer 1

Las propiedades comunes a alguna combinación aleatoria de una instancia de Person y Company pueden modelarse utilizando una "clase de asociación".

Hay una notación para esto en UML, y no es difícil crear dicho concepto en un lenguaje de programación extensible.

La idea es que cualquier par aleatorio de objetos que consta de un Person y Company tiene una relación, y esa relación es ella misma un objeto. No es ni Person ni Company, sino las cosas asociadas con la conexión entre una instancia particular de Person y Company.

Ese material (propiedades, métodos) constituye una clase: la clase de asociación Person-Company.

Hice este trabajo en Lisp antes, con algunas macros para definir una clase de asociación para un par de clases dado, y una tabla hash débil global para mapear pares de objetos a su objeto de clase de asociación (para que una persona y compañía fue posible recuperar la asociación, y esa asociación desaparecería cuando estos objetos se convirtieran en basura).

El vínculo real entre empresas y personas es fácil, utilizando, p. listas u otras estructuras de datos asociativos. Un objeto persona puede tener una lista de empresas, y viceversa. La idea de clase de asociación aborda el problema de dónde poner las cosas de la persona-compañía. Por ejemplo, cada Person tiene un rol dentro de un Company (digamos). No podemos tener una variable role en un Person porque puede tener muchos roles en muchas empresas. Ciertamente no podemos tener un role en la compañía porque ni siquiera es una persona; tiene personas asociadas que tienen roles. El rol puede ir a la asociación: problema resuelto.

Answer 2

Depende totalmente de su escenario de uso.

Si solo necesita encontrar a las personas que trabajan para una empresa, almacene la lista de personas en la empresa; si solo necesita encontrar las empresas para las que trabaja, guárdelas allí.

Tarde o temprano, probablemente encontrará que necesita modelar la relación real Persona < -> Empresa y usted creará una clase separada para representar eso. Ahora puede manejar agregar propiedades como la fecha en que comenzó el empleo, la fecha en que terminó, etc.

Answer 3

Bueno, no creo que necesite una tercera clase.

pensar en lo que un ORM (Doctrin para php, Hybernate Forn java) Qué:

En este caso sobre una capa DATABSE que tendrá 3 mesas:

Company, usuario y Company_user (tabla de unión beetween usuario y compañía que dice qué usuario pertenece a qué compañía).

También puede asignar esta situación simplemente con dos tablas db:

Company, usuario y en el usuario tiene un señalador referencia a la empresa. Por lo tanto, según esta referencia, puede decir a qué compañía pertenece el usuario.

último en un diseño de clase pienso:

• companuy clase puede contener una matriz de usuario (lista de usuario que pertenece a la empresa)
• usuario Clase puede contener una referencia a la empresa (la empresa del bleongs de usuario a)

Answer 4

Esto depende del caso de uso, pero en general de muchos a muchos relación de objeto se pueden implementar utilizando una clase de referencia

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

Así que ahora, tanto la empresa y la persona puede no pierde de vista su relación mentira

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

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