tipos - patron de inyeccion de dependencias c#
La manera más simple y rápida de romper todas las dependencias de una clase (2)
Cuando trabajo con código heredado y trato de crear pruebas, a menudo divido dependencias de clases o métodos para poder escribir pruebas unitarias usando simulaciones para estas dependencias. Las dependencias más a menudo vienen en forma de llamadas a clases estáticas y objetos creados usando la nueva palabra clave en el constructor u otras ubicaciones en esa clase.
En la mayoría de los casos, las llamadas estáticas se manejan envolviendo la dependencia estática, o si es un patrón singleton (o similar) en la forma de StaticClass.Current.MethodCall () que pasa esa dependencia por su interfaz, va al constructor.
En la mayoría de los casos, los usos de la nueva palabra clave en el constructor simplemente se reemplazan al pasar esa interfaz en el constructor.
En la mayoría de los casos, los usos de la palabra clave nueva en otras partes de la clase se manejan mediante el mismo método que el anterior o, si es necesario, crean una fábrica y pasan la interfaz de la fábrica en el constructor.
Siempre utilizo las herramientas de refactorización de Resharpers para ayudarme con todos estos desgloses, sin embargo, la mayoría de las cosas aún son trabajo manual (que podría automatizarse) y para algunas clases y métodos heredados que pueden ser un proceso muy tedioso. ¿Existen otros complementos de refactorización y / o herramientas que me puedan ayudar en este proceso? ¿Existe una herramienta de refactorización de "romper todas las dependencias de esta clase en un solo clic"? =)
Me parece que todos estos pasos son comunes para muchos desarrolladores y un problema común, y antes de intentar escribir el complemento en Resharper o CodeRush, tengo que preguntar, porque alguien probablemente ya ha intentado esto ...
ADICIONAL:
Reflexionando a las respuestas a continuación: incluso si no desea dividir todo a la vez (una ruptura total de un clic podría causar más problemas de los que ayuda), aún así es posible simplemente romper 1 dependencias de métodos, o 1-2 dependencias fácilmente, sería de gran diferencia.
Además, el código de refactorización tiene una medida de "prueba y ve lo que ocurre solo para aprender cómo encaja todo", y un salto total de un clic ayudaría a procesar toneladas, incluso si no verificas ese código en ...
Cuando se trata de dependencias de llamadas estáticas, es posible que desee retirar Moles . Es capaz de hacer la inyección de código en tiempo de ejecución para anular cualquier llamada a método estático o no virtual con su propia implementación de prueba. Esto es útil para probar código heredado que no se diseñó utilizando interfaces comprobadas de dependencia inyectada.
No creo que haya ninguna herramienta que pueda automatizar esto para usted. Trabajar con código heredado significa, como usted sabe, cambiar el código con pequeños pasos a la vez. Los pasos son deliberadamente pequeños para evitar errores. Usualmente, el primer cambio que debes hacer es uno que haga que ese código sea comprobable. Después de escribir la prueba, cambia esa parte del código de tal forma que corrige el error o implementa el RFC.
Debido a que debe tomar pequeños pasos, creo que es difícil usar una herramienta de refactorización para hacer desaparecer mágicamente todas sus dependencias. Con los sistemas heredados, casi nunca querrá hacer grandes cambios a la vez, porque el riesgo de romperse (y no descubrirlo debido a la falta de pruebas) es demasiado grande. Sin embargo, esto no significa que las herramientas de refactorización no sean útiles en este escenario. De lo contrario; ellos ayudan mucho
Si aún no lo ha hecho, le aconsejo que lea el libro de Michael Feathers Working Effectively with Legacy Code . Describe en gran detalle una serie de patrones que lo ayudan a refactorizar el código heredado a un sistema más comprobable.
Buena suerte.