c# - una - ¿Deben evitarse las clases estáticas porque dificulta la inyección de dependencias?
llamar una clase en c# (3)
¿Qué tan difícil sería modificar esas clases estáticas para utilizar la Inyección de Dependencia? Si haces que el DI sea opcional (si es posible), esencialmente puedes hacer una situación en la que puedas usar las clases estáticas para burlarse, simplemente haciendo la DI apropiadamente, sin cambiar el comportamiento "normal".
Alguien encargado de crear un conjunto "básico" de bibliotecas creó un conjunto de clases estáticas que proporcionan todo tipo de utilidades desde el registro, la auditoría y los métodos de acceso a bases de datos comunes.
Personalmente, creo que esto apesta porque ahora tenemos un conjunto de bibliotecas de Core que son difíciles de probar porque no puedo burlarme o resguardar estas clases ni hacer ninguna inyección en sus constructores.
Supongo que puedo usar TypeMock para anularlos, pero preferiría hacerlo de forma gratuita.
¿Qué piensas?
Editar
Si no crees que sean difíciles de probar, podrías dar un ejemplo de cómo los probarías. Estas clases estáticas instancian otros tipos para hacer sus funciones.
Lo siguiente es de Journal of Object Technology: Desacoplamiento de las responsabilidades de los métodos estáticos para una con fi gurabilidad de grano fino
Los métodos estáticos presentan obstáculos para el desarrollo de pruebas mediante la creación de instancias de cableado. Un estudio de 120 métodos estáticos en código abierto de Smalltalk muestra que de los 120 métodos estáticos, solo 6 no pudieron implementarse igualmente como métodos de instancia, pero no lo fueron, lo que implicó a su interlocutor con la dependencia implícita de estos métodos estáticos.
Las clases estáticas (métodos) no necesariamente deben evitarse siempre que no tengan dependencias ocultas. Por supuesto, puede pasar las dependencias a un método estático, simplemente no debe almacenarse internamente y modificar el comportamiento de las llamadas posteriores.
No debería haber problema para probarlos en este caso, también.
Pero tengo un mal presentimiento sobre los casos que mencionas también. Conozco algunas de estas clases de utilidad "wrapper" estáticas, y en la mayoría de los casos realmente apestan :)
EDITAR:
Tal vez debería aclarar. Utilizaría clases / métodos estáticos solo para tareas distinguidas muy pequeñas. Cuando las clases estáticas comienzan a inicializar las dependencias, deben evitarse. Si no puedes probar estas clases estáticas, ya tienen un trabajo demasiado grande que hacer.
En la primera respuesta de esta pregunta están los argumentos en contra de las clases estáticas como usted mencionó.