OO Design - El objeto hace una pregunta a la clase que lo mantiene indirectamente

Question

Me pregunto si un objeto que hace una pregunta a otro objeto que lo sostiene indirectamente es un diseño "malo". Por ejemplo ...

Requisitos: El carácter (un objeto) se mueve en una cuadrícula. Cuando intenta moverse a otro punto, necesita saber si ese punto ya está ocupado por algo que lo bloquea, o si esa parte de la cuadrícula es completamente inaccesible. (Tenga en cuenta que el personaje en sí necesita saber).

En la aplicación, un estado contiene un gestor de teselas y un gestor de caracteres. El administrador de teselas sabe qué teselas son accesibles y cuáles no. El gestor de caracteres conoce las ubicaciones de los mosaicos de los personajes.

¿Sería razonable que el personaje llamara a una función desde el estado, digamos AuthorizeMovement, que determina si el movimiento es posible a través de TileManager y CharacterManager, y devuelve verdadero si es así, falso si no?

¿Está violando alguno de los principios importantes, lo que ocasionará problemas en el futuro?

Obviamente esto se generaliza y se reduce a lo necesario para comprender el problema.

Answer 1

No veo ningún problema. Good OO Design viene con muchos principios. Pero en su núcleo tienes los 4 grandes: encapsulación, herencia, polimorfismo y abstracción. Además, desea alta cohesión y bajo acoplamiento. Es decir, sus objetos/clases pueden caber en cualquier lugar y no están vinculados a una implementación o clase en particular.

Dicho esto, parece que ha utilizado lo anterior para el movimiento encapsulado y los personajes los resumen en clases separadas. Entonces tu clase de Personaje no está modificando el tablero directamente, lo que sería malo si lo fuera.

A medida que comprenda mejor su problema, siempre puede refactorizar su código para mejorar su diseño y aprovechar otros principios.

Answer 2

Sugeriría que es probable que sea un mal diseño, sí. La "bandera roja", por así decirlo, es la referencia circular. Usted dijo:

... un objeto de hacer una pregunta a otro objeto que posee indirectamente que

Por lo tanto, la "explotación" objeto tiene una referencia al objeto "celebrado", y también en Para "hacer una pregunta", el objeto "retenido" necesitará una referencia al objeto "retenido".

Eso hace un gráfico circular de dependencia de objetos y es a menudo un olor a código.

Parecería que alguna otra clase debería tener la responsabilidad de conocer tanto el carácter como TileManager y/o CharacterManager.

Answer 3

No va contra ningún principio de OOP. Los detalles de la llamada se abstraen totalmente y usted depende del objeto de estado de todos modos. ¿Cómo diablos podría implementar esta función?

La abstracción y los principios son herramientas útiles. Pero no debe depender de ellos para calificar su código como bueno. No todas las abstracciones o todos los principios son buenos para cada escenario o cada implementación posible. Son pautas, no reglas. Si no puede ver rápidamente una implementación alternativa, use esta y luego regrese a ella.