Patrón de diseño del constructor: sin clase/interfaz abstracta

Question

Me pregunto si puedo implementar el patrón de diseño del constructor pero sin tener una interfaz/clase abstracta de la cual obtengo constructores de concreto. ¿Puedo tener un solo constructor?

Si sólo tengo una concretebuilder y un director Es todavía que el patrón de diseño constructor?

Para ser más específicos:

tengo algún objeto que quiero "armar" a un objeto complejo. Siendo más precisos Tengo las siguientes clases:

Puerta pared habitación

Quiero construir un "mundo" de estos classe, es decir todas estas clases combinadas me da un mundo.

Gracias

Answer 1

Se puede combinar el patrón constructor con la visitor pattern: Pasar una especie de árbol de datos para el constructor, cada uno de los cuales implementa un método accept(Visitor v), y que el constructor recorrer el árbol que pasa cada nodo nuevo en el visitante a través del método de aceptación.

Answer 2

Si acabo de tener un constructor de hormigón y un director ¿sigue siendo el patrón de diseño del constructor?

que no se quedase colgada sobre esta cuestión desde el principio. Si su proyecto solo requiere que se construya un tipo de "mundo" y realmente no necesita múltiples subclases de constructor, entonces usar un director y un solo constructor de concreto es un enfoque válido. Enfóquese en cambio en el espíritu del patrón: aislar a su director de los detalles de cómo debería construirse el mundo.

Una vez que el código está trabajando y que está satisfecho con los resultados, volver atrás y revisar cómo interactúan realmente su director y constructor. Luego, considere refaccionar el constructor para extraer una interfaz común que realmente establezca el contrato entre el director y el constructor.

Encuentro que es mucho más fácil extraer una interfaz sensible de una clase concreta que funcione, luego intentar adivinar de antemano qué podría ser esta interfaz y tratar de desarrollar la interfaz y la clase al mismo tiempo.

Answer 3

Sí, por supuesto que puede tener un WorldBuilder sencilla whos trabajo es crear un mundo totalmente configurado compuesta de puertas, paredes y habitaciones. Esto es muy útil cuando no quiere que exista un objeto World parcialmente construido y posiblemente no válido.

Digamos que el uso del constructor es así:

WorldBuilder builder = new WorldBuilder(); 

// read the definition of a room from an XML file or other source. 
// this is vastily simplified, you'd probably be iteration 
// something like this: 
// 
// for each Room in file 
//  for each wall in room 
//   for each door in wall 
// 
roomId = readRoomId(); 
wallId = readWallId(); 
doorId = readDoorId(); 
destRoomId = readDestinationRoomId(); 

builder.AddRoom(roomId); 
builder.AddWallToRoom(roomId, wallId, SIDE.NORTH); 
builder.AddDoorToWall(wallId, DOORSTYLE.WOODEN | DOORSTYLE.LOCKED, destRoomId); 

// etc, etc 

World world = builder.makeWorld(); 

Un enfoque no-constructor podría querer hacer algo como esto para conectar dos salas de objetos:

Door door = new Door(roomOne, roomTwo); 

Pero si estaban iterando cada habitación desde un archivo como antes, entonces no tendrá una referencia a la segunda sala porque es posible que aún no se haya alcanzado.

Un enfoque alternativo es dar a cada objeto sólo la identificación de sus vecinos o de los padres para que pueda obtener esto en su lugar, lo que le permite referirse a un objeto que no se ha cargado todavía:

Door door = new Door(roomOneId, roomTwoId); 

Pero si hubo un error en el archivo y la sala 2 nunca se definió, entonces el Mundo sería inválido.

The Builder puede encargarse de todos los detalles de construir, conectar y validar correctamente el proceso de creación mundial, otorgando flexibilidad al código del cliente que desea crear el mundo y recuperando el objeto mundial de lógica de construcción compleja.