27 votos

Lo que debe utilizar en lugar de un "manager" de la clase en un buen diseño de la programación orientada a objetos?

Estoy teniendo problemas con el diseño de mi motor de juego. Por ejemplo:

Cuando pienso en los Recursos, yo creo que en una clase ResourceManager clase para gestionar recursos en mi motor.

Esta clase recibe varias responsabilidades:

  • La carga de recursos.
  • Mapa de recursos por un identificador.
  • Garantizar que los recursos se carga una sola vez.
  • Libre de utilizar los recursos (uso de smartpointers).

Esto funciona para mí, pero he leído en toda la programación orientada a objetos diseño de tutorial en el que los gerentes son ambiguos clases con acoplamiento de alta y baja cohesión. Entiendo que esto, y estoy de acuerdo, pero he buscado en casi la totalidad de la Internet para encontrar un claro ejemplo de una alternativa real a los Gerentes, pero no la he encontrado.

Algunas personas explican, por ejemplo, que un ResourceManager debe ser dividida en clases más pequeñas: Una ResourceFactory, un ResourceCollection, un ResourceCache, un ResourceFacade...

Sé que todo esto patrones de diseño (de Fábrica, Colección, Fachada, etc.) Pero yo en realidad no entiendo cómo esto puede estar unido para crear un fácil de administrar) sistema de gestión de recursos.

Mi pregunta es: ¿hay algún tutorial o documento con un ejemplo claro? Puede alguien explicar un ejemplo de este sistema? Voy a agradecer a usted si usted puede escribir un pequeño ejemplo en C++ u otro lenguaje similar.

Gracias de antemano por su ayuda!

12voto

Mark Seemann Puntos 102767

Casi te dijo ya:

Esta clase recibe varias responsabilidades

(cursiva en el original).

Esto viola el Principio de Responsabilidad Único. Además, la palabra Administrador sugieren un objeto que gestiona otros objetos, que está en contradicción con el objeto-orientado a principio de que los objetos deben encapsular los datos y el comportamiento. Esto conduce rápidamente a la Función de la Envidia código de olor.

Dividiendo el administrador en muchas de las clases más pequeñas es la cosa correcta de hacer. Para mantener manejable, se puede implementar una Fachada sobre ellos.

7voto

eglasius Puntos 26221

Tal vez:

  • La carga de recursos -> ResourceLoader
  • Mapa de recursos por un identificador -> ResourceMapper
  • Garantizar que los recursos se carga una sola vez -> CachedResourceLoader / éste utiliza la ResourceLoader cuando ya no tiene la carga de la
  • Libre de utilizar los recursos (uso de smartpointers) -> ? / no está seguro acerca de esto, pero carga+descarga parece altamente cohesivo conceptos

volver a información adicional en el comentario acerca de "Libre de utilizar los recursos":

En primer lugar, dejar claro que sólo tenemos 2 de la mencionada involucrados: ResourceMapper y CachedResourceLoader. Como el ResourceLoader ejemplo, se utiliza desde el CachedResource, no expuesto al resto del código.

Tenga en cuenta que el siguiente depende del conocimiento de un dominio, así que voy a mantenerlo abierto / sabrás que estos hacen sentido / se aplica a las piezas que tiene. Yo diría que hay 3 opciones:

  • ResourceMapper utiliza CachedResourceLoader, y que sólo se exponen las anteriores para el resto del código.
    • En este enfoque, existe un único punto de entrada a través de ResourceMapper, así que tiene sentido que los controles FreeUnused().
    • Una vez que se determina que puede liberar un recurso, que va a eliminarlo del mapa. Si es necesario se llamaría una Descarga de elementos específicos para la CachedResourceLoader
  • Ambos CachedResourceLoader y ResourceMapper son utilizados por el autor de la llamada.
    • Si sólo necesita FreeUnused de la ResourceMapper, a continuación, sólo tienes que añadir allí.
    • Si necesita ser liberado de ambos, de uno de los siguientes:
    • .FreeUnused en el ResourceMapper recibe un cachedResourceLoader. Después de determinar el/la eliminación de los elementos del mapa, se pasa a la lista de recursos para liberar a la cachedResourceLoader instancia
    • .FreeUnused en el ResourceMapper devuelve la lista de los recursos liberados del mapa. La persona llama .Descargar en el cachedResourceLoader pasando la lista de recursos para Descargar. Tal vez usted tiene un bonito lugar en el que llama a estos 2 llamadas encajaría bien.
  • Usted hace uso de una clase ResourceManager, pero en lugar de tener todas las implementaciones de allí, utiliza el ResourceMapper y CachedResourceLoader. Sería muy delgado, con sólo hacer llamadas a los otros, en particular los .FreeUnused y .Descargar llamadas en la última sub apartado anterior.

Una nota final: creo que es definitivamente vale la pena separar las responsabilidades y se sienten fuertes acerca de hacerlo. Dicho esto, los SÓLIDOS principios que sigue la mayoría, yo no memorizar el patrón de nombres y no le presta mucha atención a las reglas como Administrador de las clases son malos.

6voto

Jani Puntos 9200

Pero no creo que eso no es necesariamente algo malo con su solución. En mi humilde opinión si usted piensa acerca de las cosas que usted dijo que a partir de la Programación Orientada al Aspecto's punto de vista, es sólo un aspecto de sus recursos que va a ser manejado por la clase.

Aunque si piensas en grande y su base de código puede evolucionado en cientos de línea de código, será mejor para romper su Infraestructura de funciones(Domain Driven Design Patrones).

Creo que la clase es un cohesivo uno y el nombre del administrador no es siempre una mala señal, excepto que se consolida el control de flujo de muchos posiblemente relacionado clases que colaboran entre sí para realizar una tarea.

Me comentan que si sus requisitos de almacenamiento en caché de mapeo y es propenso a cambiar tal vez será mejor que Separados de sus Preocupaciones.

6voto

CesarGon Puntos 8710

Usted no necesita ser dogmático acerca de los patrones de diseño o una arquitectura particular. Acabo de hacer lo que tiene sentido y documento de bien.

En otras palabras, la descomposición de una clase en clases más pequeñas, porque la clase más grande tiene múltiples responsabilidades es un buen principio, pero no un derecho. Usted no quiere seguir a toda costa. Mira los pros y los contras de su aplicación. A veces, la descomposición de una clase en clases más pequeñas le da más control sobre responsaibilities, pero a expensas de una gran cantidad de comunicación entre las clases. En tu ejemplo, usted podría implementar diferentes clases de recursos de la carga, el almacenamiento en caché, de asignación, de ahorro, etc. Pero si cada una de las necesidades de la clase para hablar con los otros para realizar su trabajo, entonces la descomposición es que no vale la pena hacerlo, ya que implica un alto acoplamiento, lo que es malo; de mantener a todos en una sola clase.

A veces pienso que los patrones de diseño han provocado tanto daño como la claridad para el desarrollo de software en el mundo! :-)

2voto

jalf Puntos 142628

Sé que todo esto patrones de diseño (de Fábrica, Colección, Fachada, etc.) Pero yo en realidad no entiendo cómo esto puede estar unido para crear un fácil de administrar) sistema de gestión de recursos.

Quién dice que deben estar unidos? Entonces estás de vuelta donde había empezado, no? Todo el punto de romper el administrador de clases, es que usted termina con múltiples componentes más simples. Si usted necesita el almacenamiento en caché de la funcionalidad, de hablar a la caché. Si usted necesita la carga de recursos de la funcionalidad de hablar con el cargador de recursos.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X