¿Un mejor diseño? Mismo objeto, diferentes estados posibles

Question

Tengo una aplicación muy simple que consiste en un sitio front-end ASP.NET, con un servicio WCF de Windows haciendo la lógica de back-end de trabajo pesado.

El usuario tiene una página simple donde selecciona algunos parámetros y presiona el botón 'enviar'. La página llama al servicio WCF y le pasa los parámetros. El servicio instancia una instancia de una clase 'Job', envía los parámetros al constructor, luego llama a un método 'Run ()' que hace todo el trabajo de: insertar un registro 'job' en una base de datos con el nombre de usuario, hora iniciado, etc. Realiza una solicitud a un proveedor externo, toma los datos, los coloca en la base de datos, realiza alguna otra lógica comercial y luego marca el trabajo como completado.

El usuario tiene una segunda página simple donde ahora puede buscar su trabajo (un cuadro combinado de búsqueda ordenado por fecha, que muestra múltiples campos relacionados con ese trabajo) y luego muestra los datos correspondientes a ese trabajo en la pantalla - (

Ahora a mi pregunta, así que tengo una clase Job que tiene todos los campos mencionados anteriormente, junto con su método y constructores públicos Run (). Tiene algunas funciones privadas simples y varios miembros privados que son interfaces para clases como IParser, IVendorConnection, IDataAccess, las clases que hacen todo el trabajo real descrito anteriormente. La clase de trabajo real y el método Run () no hacen mucho. trabajo real, prácticamente solo los delegados trabajan en sus objetos compuestos (lo que permite una buena capacidad de prueba, entre otras cosas).

Ahora, esta clase de trabajo tiene 3 diferentes usos / estados posibles. Su uso principal está dentro del Servicio, para el uso de la función Run () para ejecutar literalmente un trabajo. También tiene otros 2 usos: actuar como modelo para el panel que describí anteriormente y actuar como modelo para el cuadro combinado que describí anteriormente. La clase de trabajo tiene 3 constructores públicos, cada uno de los cuales lo configura para uno de los 3 estados. En todos los casos, cada 'estado' diferente solo se preocupa por ciertos miembros que a los otros 2 estados no les importan; en algunos casos, algunos de los miembros se usan en los 3 estados. El 'estado del cuadro combinado' es el más simple; en este caso, solo quiero 3 campos de solo lectura. En el 'estado del panel' me interesan 6 campos de solo lectura ... en el estado 'trabajo' básicamente estoy creando estos valores de campo a medida que avanza el trabajo, y todos deberían ser privados.

Solo estoy buscando una forma más limpia de hacer esto. Si instancia una clase de trabajo en el estado A, sé que acceder al miembro X no funcionará o que la función de llamada Y fallará. Sin embargo, sigue siendo código compilable.

Estoy seguro de que otros se han enfrentado a este problema antes. Estaba pensando en tener una clase de trabajo base marcada como MustInherit / abstract, y luego tener 3 clases derivadas, una para cada estado. Coloque los miembros compartidos en la base y los específicos del estado en el derivado, y simplemente use las clases derivadas en mi código cuando corresponda. Esto parece bastante simple para mis propósitos y resuelve mi problema. Tal vez también podría tener algún tipo de JobFactory ... Supongo que solo estoy buscando cómo otras personas resolvieron esto, ya que tal vez no estoy pensando lo suficiente fuera de la caja ... He tenido muchas clases de máquinas de estado antes en mi días de desarrollo de juegos de aficionados, pero eso fue diferente, porque las instancias de esas clases podían cambiar de estado (por ejemplo, una clase de 'Enemigo' podría cambiar su estado de 'ataque_modo' a 'esperar'). En mi caso, no hay estados cambiantes: Una vez creado, un trabajo debe permanecer en su estado y nunca tratar de comportarse en uno diferente. El estado de seguimiento y las excepciones de lanzamiento si se usa un método / miembro mientras no se encuentra en un estado dado parece frágil y demasiado trabajo. ¿Alguna sugerencia basada en cómo ha resuelto este problema antes? ¿Y es lo que estoy tratando de hacer demasiado? Si el trabajo sta

Answer 1

Su idea de crear un trabajo de clase base única con 3 clases derivadas suena exactamente igual a lo que yo haría también. Crear un JabFactory podría ayudar aún más a este diseño. Puede ser una mala práctica crear un objeto donde partes del objeto no se usen o sean ilegales en ciertas circunstancias. Por lo tanto, crear las clases derivadas con solo las partes necesarias es claramente el mejor diseño. No es exagerado.