SRP aplica a un ejemplo de flujo de trabajo: cómo estructurar las clases de una manera sensata

Question

Tengo un problema de decidir acerca de las responsabilidades de la clase.
Tengo 3 html formas:

1. Para cada forma hay una plantilla HTML que contiene un poco de texto y un marcador para la forma que se incluirán
2. necesita Cada forma de ser validado, si hay un error la plantilla y la forma de (1) las necesidades a vuelve a mostrar junto con algunos mensajes de error. Sólo algunos campos son comunes a través de las diferentes formas.
3. Si no hay errores de un mensaje de resultado debe ser enviado por correo. Para cada forma hay una plantilla de correo de resultado.

Me resulta muy difícil decidir sobre un plan de buena clase para este problema. Una posibilidad consiste en clases que separan por la funcionalidad

• CheckFormData: comprobación de datos de formulario
• DisplayForm: forma de la pantalla con / sin errores (? O separar esto también)
• EmailForm:. Emailform

No estoy seguro acerca de esto. El conocimiento acerca de los campos de una forma particular, se dispersan al otro lado de las distintas clases.

Hay un poco de flujo de trabajo. Tal vez yo también debería tener una clase de flujo de trabajo:

class FormSubmitWorkFlow
{
   function start() 
   {
     $this->displayForm->render();
   }

   function processFormData($data)
   {
      $this->checkForm->setData($data);
      if (!$this->checkForm->isValid())    {

         $errors = $this->checkForm->getErrors();
         $this->displayForm->setData($data)->setErrors($errors)->render();
      } else {
         $this->emailForm->setData($data)->email();
      }
   }

   function setDisplayForm(DisplayForm $df)
   {
      $this->displayForm = $df;
   }

   function setCheckForm(CheckForm $cf)
   {
      $this->checkForm = $cf;
   }

   function setEmailForm(CheckForm $ef)
   {
      $this->emailForm = $ef;
   }
}

Para cada tipo de formulario (recuerde, hay 3 de ellos) que iba a necesitar un

1. CheckForm,
2. EmailForm y
3. clase DisplayForm.

3 * 3 = 9 + 3 clases de base = 12 clases de clases.
Además, desea inyectar la derecha checkForm-subclase y EmailForm-subclase en el flujo de trabajo, todos ellos necesitan ser del mismo tipo de formulario. Tal vez tenemos que crear un FormWorkFlowFactory para esto. Esto se suma a 13 clases.

Ahora me dio la sensación de que estoy haciendo algo muy mal. Si tuviera FormSubmitWorkFlow como clase Template Method, tan sólo pudiera crear 3 subclases, pero cada subclase gustaría mezclar diferentes responsabilidades.

¿Cómo podría mejorar esto, y podría motivar su respuesta, es decir, lo que conduce método que a su respuesta?

---

editar : si bien la respuesta sólo es útil actual, sería agradable ver algunos votos de las personas que están de acuerdo con él, o me gustaría escuchar las mejores soluciones de la comunidad. Soy el único que upvoted esta respuesta. Esta pregunta podría utilizar más la entrada, así que no dude de proporcionar de manera: -)

Answer 1

No estoy seguro de si esto va a responder a su pregunta o no, pero, obviamente, el objetivo de la SRP es escribir el código para que si tiene que cambiar algo, es por una sola razón. Al igual que si el coche tenía SRP entonces no habría una clase que ajusta la temperatura y también por las ventanas de arriba a abajo. Eso violaría el principio. En este caso parece que están haciendo las cosas bien. Sí, es un montón de clases, pero la alternativa es una gran confusión. A menos que hubiera una manera que se podría crear una sola clase que validaría las formas (que en realidad debería ser posible dependiendo de qué tipo de verificación que necesita).

Si ha creado una clase de verificación donde se puede simplemente añadir una cadena de valores esperados y ver si coinciden, probablemente tendría clases más generales, pero creo que sería mucho menos acoplada. Déjeme saber si he entendido bien o no.