¿Los métodos estáticos privados en C # dañan algo?


10

Creé un método de validación privado para una cierta validación que ocurre varias veces en mi clase (no puedo almacenar los datos validados por varias razones). Ahora, ReSharper sugiere que la función podría hacerse estática. Soy un poco reacio a hacerlo debido a problemas conocidos con los métodos estáticos. Sería un método estático privado . Mi pregunta es, ¿pueden los métodos estáticos privados causar problemas similares de acoplamiento y prueba como los métodos estáticos públicos? ¿Es una mala práctica? Supongo que no, pero no estoy seguro si hay una trampa aquí.


10
¿Cuáles son los "problemas conocidos" con los métodos estáticos?
Robert Harvey

3
@Ed: Correcto. Los métodos estáticos escritos correctamente no deberían tocar las API externas o el estado de todos modos. Manipular el estado interno encapsulado dentro de una clase me parece perfectamente correcto, y el método no necesitaría ser probado por la unidad, ya que las pruebas unitarias prueban el comportamiento externo de la clase.
Robert Harvey

1
Los métodos estáticos son propensos a modificar el estado global y también eliminan la herencia (cada vez que desee ampliar la funcionalidad, deberá modificar el código de llamada porque no puede anular el método en una clase derivada). Estás atado a esa única implementación. Los métodos estáticos no se pueden burlar, lo que los hace muy difíciles de realizar pruebas unitarias. Ocultan dependencia . Estoy seguro de que hay más. No solo para evitarlos a ciegas, les pido que tomen una decisión informada.
Tamás Szelei

2
@ Tamás Los métodos estáticos solo modifican el estado global si los escribe de esa manera, lo cual nunca hago. En términos generales, solo uso métodos estáticos en clases de utilidad, métodos que toman uno o más objetos y devuelven un objeto sin efectos secundarios. Este tipo de métodos no tiene ninguno de los problemas que describe.
Robert Harvey

1
@ TamásSzelei ¿Cómo son propensos a modificar el estado global? Ni siquiera pueden encontrar el estado global a menos que lo pase a un parámetro.
CodesInChaos

Respuestas:


16

Yo pensaría: "¿Necesito probar esto?"

Si su método es privado de todos modos, lo que significa que no desea probar la lógica de la unidad en el método en sí mismo, entonces, en lo que respecta a la capacidad de prueba y la capacidad de mantenimiento, su clase es una caja negra de cualquier manera, el funcionamiento interno de su clase es su negocio. Y está solo. La refactorización tampoco se verá afectada, lo que también es algo a considerar.

Entonces, en mi opinión: No, hacer un método "privado" "privado estático" no tendrá ramificaciones a largo plazo.


17

Los métodos estáticos privados son lo más fácil posible, desde mi punto de vista.

DataIn -> Método -> DataOut

No hay dependencias en objetos externos, no hay efectos secundarios. ¿Por qué los consideras malos?


Gracias. Expliqué mis preocupaciones en los comentarios bajo la pregunta.
Tamás Szelei

2
Lo que describe solo es correcto para los métodos estáticos que no dependen de las variables miembro estáticas; eso es lo que puede marcar la diferencia entre un método estático "bueno" y uno "malo".
Doc Brown

2

Las clases de prueba que usan métodos estáticos públicos pueden ser difíciles, ya que no es (particularmente) fácil tropezar / falsificar / burlarse de los métodos estáticos. Los métodos de instancia, por otro lado, se pueden burlar fácilmente, especialmente si son virtuales o satisfacen una interfaz.

Sin embargo, no veo ninguna razón para no usar métodos estáticos privados. De hecho, hay un ligero beneficio de rendimiento, ya que no necesita una instancia de la clase para ocupar memoria.

Por otro lado, cualquier cosa estática es un poco un olor a código. ¿Es esto realmente una "clase auxiliar"? ¿Podría ser que el método podría residir más útilmente en una de las clases pasadas como parámetro? La respuesta a esas preguntas es a menudo "está bien como estática", pero vale la pena recordarla.


La clase que contiene el método estático ya está ocupando memoria de todos modos. Su miedo a la staticpalabra clave parece infundado.
Robert Harvey
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.