C ++ pregunta el diseño de programas

Question

En los últimos par de proyectos en los que tomaron parte en casi fui adicto al patrón de codificación siguiente: (no estoy seguro si hay un nombre propio para esto, pero de todos modos ...)

Supongamos que un objeto está en un estado determinado y que wa no para cambiar este estado desde el exterior. Estos cambios podrían significar cualquier comportamiento, podrían invocar cualquier algoritmo, pero el hecho es que se centran en el cambio de estado (Estado miembro, estado de datos, etc ...) de algún objeto.

Y la llamada de una manera discreta nos dejó de cambiar los objetos de una Mutator. Mutators se aplica una vez (en general) y tienen algún método interno como apply(Target& target, ...), lo que provoca al instante cambiar el estado del objeto (de hecho, son una especie de objetos funcionales).

También podría asimilarse fácilmente en cadenas y se aplica uno por uno (Mutator m1, m2, ...); también podrían derivarse de alguna BasicMutator básica con el método virtual void apply(...).

Me han introducido clases llamadas InnerMutator y ExplicitMutator que difieren en términos de acceso - el primero de ellos también puede cambiar el estado interno del objeto y debe ser declarado como amigo (friend InnerMutator::access;)

---

En aquellos proyectos de mi lógica volvió a trabajar de la siguiente manera:

1. Preparar mutators disponibles, elegir cuál de aplicar
2. Crear y configurar el object a un estado determinado
3. foreach (mutator) mutator.apply(object);

Ahora la pregunta.

  

Este esquema turnes funcione bien y    (para mí) parece como una muestra de algunos no estándar de diseño, pero útil   modelo.

     

Lo que me hace sentir incómoda es que la materia InnerMutator. que no lo hacen   pensar en declarar mutador a un amigo   cada objeto que estado podría ser   cambiado es una idea buena y yo wan't   encontrar la alternativa apropiada.

     

¿Podría esta situación se resuelve en términos de Mutators o podría   asesoramiento algún patrón alternativo con   el mismo resultado?

Gracias.

Answer 1

Espero que esto no se toma la ofensiva, pero no puedo evitar pensar en este diseño es una solución demasiado sofisticado para un problema bastante simple.

¿Por qué necesita para mutators agregados, por ejemplo? Uno puede simplemente escribir:

template <class T>
void mutate(T& t)
{
    t.mutate1(...);
    t.mutate2(...);
    t.mutate3(...);
}

No es tu mutador agregada, sólo que es una plantilla simple función depender de polimorfismo estática en lugar de una lista combinada de mutators haciendo una super-mutador.

Una vez hice algo que podría haber sido bastante similar. Hice objetos de función que podría ser combinados por el operador && en objetos función SUPER que se aplicaban los dos operandos (en el orden de izquierda a derecha) de modo que uno podría escribir código como:

foreach(v.begin(), v.end(), attack && burn && drain);

estaba muy bien y parecía muy inteligente para mí en ese momento y fue bastante eficaz porque genera nuevos objetos de función sobre la marcha (no hay mecanismos de ejecución involucrados), pero cuando mis compañeros de trabajo, viéndolo, se pensó que estaba insano. En retrospectiva, yo estaba tratando de meter todo en la programación de estilo funcional que tiene su utilidad, pero probablemente no debería ser demasiado confiado en en C ++. Habría sido bastante fácil de escribir:

BOOST_FOR_EACH(Something& something, v)
{
    attack(something);
    burn(something);
    drain(something);
}

Por supuesto que es más líneas de código, pero tiene la ventaja de ser centralizada y fácil de depurar y no introducir conceptos ajenos a otras personas que trabajan con mi código. He descubierto que es mucho más beneficioso en lugar de centrarse en la lógica apretado en lugar de tratar de reducir la fuerza de líneas de código.

Te recomiendo que piensa profundamente acerca de esto y realmente considerar si vale la pena continuar con este diseño basado en mutador no importa lo inteligente y apretado que es. Si otras personas no pueden entender rápidamente que, a menos que tenga la autoridad de los autores de impulso, que va a ser difícil convencer a la gente le gusta.

En cuanto a InnerMutator, creo que se debe evitar como la peste. Tener clases de mutantes externos que pueden modificar componentes internos de una clase tan directamente como sea posible aquí una gran cantidad de derrotas el propósito de tener elementos internos en absoluto.

Answer 2

¿No sería mejor simplemente hacer esas Mutators métodos de las clases están cambiando? Si hay una funcionalidad común desea que varias clases tengan por qué no hacer que se heredan de la misma clase base? Hacer esto se ocupará de todas las molestias mutador interior me imaginaría.

Si quieres hacer cola cambios que podría guardarlas como conjuntos de llamadas de función a los métodos dentro de las clases.