oop - materials - maven scope runtime
Dos objetos con dependencias entre ellos. ¿Es tan malo? (4)
Estoy aprendiendo mucho sobre los patrones de diseño cuando estoy construyendo mi propio sistema para mis proyectos. Y quiero preguntarle acerca de una pregunta de diseño a la que no puedo encontrar una respuesta.
Actualmente estoy construyendo un pequeño servidor de chat usando sockets, con múltiples clientes. En este momento tengo tres clases:
- Persona-clase que contiene información como nick, age y Room-object.
- Clase de sala que contiene información como nombre de sala, tema y una lista de personas que se encuentran actualmente en esa sala.
- Clase de hotel que tiene una lista de personas y una lista de habitaciones en el servidor.
He hecho un diagrama para ilustrarlo:
Tengo una lista de personas en el servidor en la clase del hotel porque sería bueno hacer un seguimiento de cuántos hay en línea en este momento (sin tener que recorrer todas las salas). Las personas viven en la clase Hotel porque me gustaría poder buscar una Persona específica sin buscar en las habitaciones.
¿Es este mal diseño? ¿Hay alguna otra forma de lograrlo?
Gracias.
En un sistema más grande, sería malo, pero por lo que entiendo de tus aplicaciones, estas tres clases solo se usan juntas, no es un gran problema. Solo asegúrese de nombrar las variables de miembro de la persona de una manera que indique que contiene una referencia a una sala, en lugar de una instancia.
Además, a menos que sea por motivos de rendimiento (p. Ej., Tendrá una gran cantidad de habitaciones), probablemente sería más limpio crear una propiedad o getter que recorra las habitaciones y recopile a las personas, en lugar de guardarlas en caché en el hotel.
La dependencia mutua no es mala por sí misma. A veces, el uso de datos lo requiere.
Lo pienso de una manera diferente. Será más fácil mantener un código que tenga menos relaciones en general, dependencia mutua o no. Solo mantenlo lo más simple posible. El único truco adicional con su situación es a veces que hay un problema de verificación y huevo, durante la creación y eliminación de secuencias. Tienes más enlaces para reservar.
Si está preguntando si necesita una lista de personas en un hotel en este caso, creo que hay dos respuestas. Comenzaría teniendo sus objetos (en la memoria) suministrando estas relaciones, pero NO necesita una tabla adicional de unión entre personas y hoteles en la base de datos. Si está utilizando Hibernate, generará automáticamente una unión eficiente para usted si lo solicita a las personas en un hotel (se unirá a los hoteles en rooms.hotel_id para usted).
No me gusta Un hotel contiene habitaciones y las habitaciones contienen personas. Las personas no tienen habitaciones, ellas les pertenecen.
No necesariamente tiene que iterar para obtener el conteo de sus invitados. Podrías mantener un recuento continuo ($ Hotel-> total_guests) y modificarlo a medida que cambie.
El problema de dependencia mutua entre las clases, estrictamente hablando, se puede resolver mediante el uso de interfaces (clases abstractas, si su lenguaje es, por ejemplo, C ++ o Python) IRoom e IPerson ; en pseudocódigo
interface IPerson
IRoom getRoom()
// etc
interface IRoom
iter<IPerson> iterPerson()
// etc
esto hace que solo las interfaces sean mutuamente dependientes entre sí; las implementaciones reales de las interfaces solo dependen de las interfaces.
Esto también le da mucho margen en términos de implementación, si quiere evitar bucles circulares de referencia (que pueden ser molestos, por ejemplo, en CPython al ralentizar las recolecciones de basura) - podría usar referencias débiles, una base de datos relacional subyacente con un típico " tabla de relación de uno a muchos, etc., y para el primer prototipo simple puede usar lo que es más simple en su lenguaje elegido (probablemente simples, y alas necesariamente circulares, referencias [[punteros, en C ++]] con una Person refiriéndose a un Room y una Room a una list<Person> ).