2011-08-09 18 views
6

Veo esto bastante y me preguntaba si había alguna manera de refactorizar esto para evitar el cambio masivo. Este es un método en una fábrica: RoomControllerFactory, instanciando una ubicación de juego según su tipo. He aquí un ejemplo de un cambio en el método de fábrica:¿Hay alguna alternativa a cambiar en un método de fábrica?

  switch (location.getType()) 
      { 
       case Location.ROOMONE: 
        return new RoomOneController(location, data, view);   

       case Location.ROOMTWO: 
        return new RoomTwoController(location, data, view); 

       case Location.ROOMTHREE: 
        return new RoomThreeController(location, data, view); 
+0

No sé actionscript, pero usaría una tabla hash para registrar los tipos de las diferentes ubicaciones con un RoomControllerFactory que a su vez puede instanciar el RoomController correcto. tan pronto en C# inicialmente roomControllerFactories [location.getType()] = new RoomOneControllerFactory(); seguido más tarde por: roomControllerFactories [location.getType()]. ​​create (ubicación, datos, vista); – Polity

+1

¿Se instancian estas instancias de RoomController más de una vez en el programa? Por ejemplo, si fuera un laberinto, ¿tendría varias instancias de TeeIntersectionRoomController? ¿O estos casos son absolutamente únicos en el juego, por ejemplo, BuckinghamPalaceThroneRoomController? Esto * podría * afectar la mejor solución ... – jpwrunyan

+0

Existen al mismo tiempo, es decir, cuando vas a la ubicación, pero actualmente están instanciados más de una vez, es decir, si vuelves a roomone recrearemos la habitación 1. Pero también algunos las habitaciones son únicas, algunas son lo suficientemente abstractas, pueden usarse para representar a más de una, por ejemplo, una tienda de tipo de habitación puede usarse para diferentes ubicaciones solo por datos, a la venta, pero una habitación tipo habitación propia solo se usará una vez. Espero que eso esté claro. :) – serenskye

Respuesta

3

Respuesta corta, cambio de fábricas, eso es lo que hacen: el objetivo de este estilo de fábrica es centralizar la lógica de construcción en un solo lugar en lugar de tenerlo en la base del código.

Siempre que no esté utilizando una fábrica estática y codificando una interfaz IRoomControllerFactory, obtendrá todos los beneficios habituales de OOP al cambiarlo en tiempo de ejecución/para probarlo. Después de todo, dice 'Yo RoomControllerFactory, dame ¡una habitación para este identificador mágico!

Como una respuesta adicional a su pregunta, es posible que desee preguntarse por qué necesita tantas instancias concretas de RoomController? Tal vez al favorecer la composición sobre la herencia, ¿podría refactorizar las cosas para usar un Constructor?

4

En vista de que está utilizando un truco para proporcionar la funcionalidad de enumeración - ¿Por qué no añadir un método para su enumeración:

public static const ROOMONE : LocationType = new LocationType("locationone", 
    function(...) : RoomController { 
     return new RoomOneController 
    } 
); 

(excusa los errores tontos - actionscript no es mi primera lengua!)

en java que haría similar con:

public enum LocationType { 
    ROOMONE { 
     @Override 
     public RoomController getRoomController() { 
      return new RoomOneController(); 
     } 
    }; 
    public abstract RoomController getRoomController(); 
} 
+0

Sí, eso ciertamente parece una solución más limpia, reduce los cambios para agregar una ubicación a un lugar y la fábrica no necesita saber de qué se trata :) – serenskye

+0

Corrígeme si me equivoco, pero esto evita el original " fábrica "completamente, ¿verdad? Dado que la fábrica solo estaba verificando un valor enum y escupiendo una instancia de clase, ¿verdad? Siento que me falta algo ... – jpwrunyan

+1

En este caso, sí. Pero en un sentido más amplio, podría ser necesaria una mayor implementación en el objeto específico devuelto que podría justificar el mantenimiento de la fábrica. – Martyn

Cuestiones relacionadas