Cuando la llamada al módulo se pone fea

7

¿Te ha pasado esto alguna vez? Usted tiene un conjunto de módulos bien diseñados, de responsabilidad única, cubiertos por pruebas de unidad. En cualquier función de nivel superior que codifiques, estás (95% del código) simplemente tomando la salida de un módulo y pasándola como entrada al siguiente. Luego, observará que esta función de nivel superior se ha convertido en un script de más de 100 líneas con múltiples responsabilidades.

Aquí está el problema. Es difícil (imposible) probar ese guión. Al menos, así parece. ¿Estás de acuerdo? En mi proyecto actual, todos los errores provienen de este script.

Más detalles: cada script representa una solución o algoritmo único, formado por el uso de diferentes módulos de diferentes maneras.

Pregunta: ¿Cómo puedes remediar esta situación?

Respuesta inmediata: divida la secuencia de comandos en módulos de responsabilidad única.
Comenta la respuesta automática: ¡ya lo es!

Mejor respuesta que puedo encontrar hasta ahora: cree objetos de conector de nivel superior que "conecten" los módulos de maneras particulares (tome la salida de un módulo, aliméntela como entrada a otro módulo). Así si nuestro guión fuera:

Foo.Input fooIn = new Foo.Input(1, 2);
Foo.Output fooOutput =  fooModule.operate(fooIn);
Double runtimevalue = getsomething(fooOutput.whatever);
Bar.Input barIn = new Bar.Input( runtimevalue, fooOutput.someOtherValue);
Bar.Output barOut = barModule.operate(barIn);

Se convertiría con un conector:

FooBarConnectionAlgo fooBarConnector = new fooBarConnector(fooModule, barModule); 
Foo.Input fooIn = new Foo.Input(1, 2);
Bar.Output barOut = fooBarConnector.operate(fooIn);

Entonces, la ventaja es que, además de ocultar algunos códigos y aclarar las cosas, podemos probar FooBarConnectionAlgo.

Estoy seguro de que esta situación sube mucho. ¿Qué haces?

    
pregunta Pete 01.06.2012 - 16:52

3 respuestas

6

Lo has hecho bien. Esto se llama "Programación Estructurada". Funciona bien cuando tiene un problema que resolver con una serie de pasos secuenciales. Simplemente divide cada problema en algunos subproblemas, luego desglose los subproblemas, luego desglose los sub-subproblemas, luego ... Parece que estás en el punto donde tienes una subrutina de nivel superior. --er, método , y un grupo de niveles inferiores. La parte superior está creciendo, así que necesitas una capa intermedia, por así decirlo. Si su problema (me gustaría llamarlo programa, pero en realidad es una parte de un programa) es lo suficientemente grande, podría terminar con muchos niveles de métodos.

Las acciones de cada método deben ser determinadas únicamente por los parámetros que se le pasan. Yo digo que esto sea completo; Con su enfoque en las pruebas, entiendes esto así como cualquier evangelista del Programa Estructurado antiguo. Idealmente, cada método se llamaría desde más de un lugar, demostrando que generalmente es útil, pero es mejor que los métodos utilicen sub-métodos a los que solo llaman, y que solo llamen una vez, que el método principal se vuelva grande y poco seguro. .

No estoy seguro de cómo se relacionan la Programación estructurada y la POO. Parece que se mezclan bien, y siempre es obvio cuándo usar qué. OO parece más para rastrear y mantener el estado de un programa, para manejar la entrada periódica de los usuarios y demás. SP es más para números crujidos. Descubrí que cuando escribo grandes números, las clases comienzan a introducirse en los niveles más bajos de mi jerarquía SP.

    
respondido por el RalphChapin 01.06.2012 - 19:53
2

Creo que a lo que te refieres es a una prueba de integración. Por lo general, tendría un conjunto de datos de prueba y resultados conocidos, al igual que para una prueba unitaria, pero en este caso está probando todo el trabajo integrado, en lugar de un solo módulo aislado.

Una prueba de integración no puede llegar a todos los rincones y grietas de cada bit de código, pero te dará bastante confianza de que lo has conectado todo correctamente.

    
respondido por el Scott Whitlock 01.06.2012 - 19:29
1

En el aislamiento, creo que estás en el camino correcto. No estoy seguro de molestarme en escribir "conectores" que unan módulos para cada caso específico. Sin embargo, tiene tiene sentido crear objetos que realicen la lógica y puedan tener sus dependencias inyectadas en ella. ¿Por qué no hacerlo solo para el "script" completo? Entonces el script en sí es comprobable. Luego puede inyectar simulacros o "dobles" para asegurarse de que las cosas sucedan de la manera que usted espera. Después de todo, espero que lo que importa sea el script completo, en lugar de cada interacción individual entre los módulos.

    
respondido por el Jeremy Heiler 01.06.2012 - 19:23

Lea otras preguntas en las etiquetas