No, no hay absolutamente ningún patrón estándar.
Mi consejo es evitar la trampa del diseño OO novato de tratar de encontrar una única interfaz común de "clase base" para todo. Tu Dragón es muy diferente de tu Mago, y no hay nada que ganar al intentar fusionar las dos interfaces, excepto las extrañas abstracciones de código. Recuerde, la herencia no es una herramienta para la reutilización de código.
El enfoque más simple es que cada objeto mantenga su propio estado interno (como ya se ha descrito), y sea capaz de dibujar ese estado. Aquí es donde una declaración de cambio de escuela anterior puede ser más claro que usar polimorfismo para el mismo efecto. Ejemplo:
class Dragon {
enum State { asleep, flying, breathing_fire };
public:
void draw() { /* old-school switch */
switch (cur_state){
case asleep: draw_asleep();
case flying: draw_flying();
case breathing_fire: draw_breathing_fire();
}
}
private:
void draw_asleep();
void draw_flying();
void draw_breathing_fire();
};
experimentados desarrolladores de C++ se jadear en el código anterior (como debe ser), debido a que la sentencia switch es casi exactamente lo que una llamada al método polimórfico lograría - envío en tiempo de ejecución. (O incluso más críptico: una tabla de direcciones de métodos.) Mi opinión personal es que para este tipo específico de clase, es decir, una única interfaz pública que encapsula una máquina de estados, la declaración de cambio es más clara y fácil de mantener porque hace que la máquina de estados saltar explícitamente Creo que también está claro que reconozco que esto es generalmente mal diseño C++.
La fricción de este diseño es causada por la línea divisoria entre la máquina de estado y la interfaz pública única. Un dragón dormido claramente no es lo mismo que un dragón volador. De hecho, no tendrá casi nada en común. Pero el diseño de nivel superior dice que los dos son el MISMO dragón. ¡Que desastre! ¿Creas diferentes objetos de Dragón para cada estado? No, porque eso expondría el concepto de estado a la persona que llama. ¿Creas diferentes objetos auxiliares internos para cada estado y los envías a esos? Posiblemente, pero se vuelve desordenado rápidamente. El enfoque anterior es un compromiso entre los dos.Piense en la declaración del interruptor como aislando la fealdad. La interfaz pública está limpia, al igual que la interfaz privada. Solo la declaración del interruptor contiene el desastre sucio. Considere este enfoque, y también considere otras sugerencias también.
Por último, señalar a su asistente y su dragón, una plantilla simple envoltorio o funtor un botón:
struct Draw {
template <class S>
void operator()(S& s) { s.draw(); }
};
El punto es que usted no tiene que combinar dos clases diferentes simplemente porque ambos apoyan la misma operación lógica.
Roba ideas de juegos de código abierto existentes. –
std :: map - para almacenamiento interno de estado a animación, y cualquier formato abierto para almacenamiento externo. –
W55tKQbuRu28Q4xv