c# - son - ¿Por qué los miembros de una clase estática deben declararse como estáticos? ¿Por qué no es solo implícito?
un método estático (8)
Daría un paso más y preguntaría: ¿Por qué C # tiene clases estáticas? Parece un concepto extraño, una clase que no es realmente una clase . Es solo un contenedor, no puede usarlo para escribir variables, parámetros o campos. Tampoco puede usarlo como un parámetro de tipo. Y, por supuesto, nunca puedes tener una instancia de dicha clase.
Prefiero tener módulos, como en VB.NET y F# . Y luego, el modificador estático no sería necesario para evitar confusiones.
Obviamente no puede haber un miembro de instancia en una clase estática, ya que esa clase nunca podría ser instanciada. ¿Por qué tenemos que declarar a los miembros como estáticos?
Esto es porque copiar y pegar sería más complicado.
Si copia un método de una clase estática a una clase no estática, entonces deberá agregar la palabra clave static .
Si copia un método de una clase no estática a una clase estática, deberá eliminar la palabra clave static .
Mover los métodos es lo primero que hacen los desarrolladores (''Necesito refactorizar este código, tomará al menos una semana''), y al hacerlo más fácil, Eric y su equipo nos permitieron ahorrar horas de trabajo.
Me hacen preguntas como esta todo el tiempo. Básicamente, la pregunta se reduce a "cuando el compilador puede deducir un hecho sobre un miembro declarado si la declaración explícita de ese hecho es (1) requerida, (2) opcional o (3) prohibida".
No hay una respuesta fácil. Cada uno debe tomarse caso por caso. Se requiere poner "estático" en un miembro de una clase estática. Poner "nuevo" en un método de ocultación y no anulación de una clase derivada es opcional. Poner "estática" en un const está prohibido.
Considerando brevemente su escenario, parece extraño prohibirlo. Tienes toda una clase llena de métodos marcados como "estáticos". ¿Decides hacer la clase estática y eso significa que tienes que eliminar todos los modificadores estáticos? Eso es raro.
Parece extraño hacerlo opcional; supongamos que tiene una clase estática y dos métodos, uno marcado estático, uno no. Como la estática normalmente no es la predeterminada, parece natural pensar que se pretende una diferencia entre ellos. Hacerlo opcional parece ser potencialmente confuso.
Eso lo hace necesario, como la menos mala de las tres opciones.
Consulte http://blogs.msdn.com/b/ericlippert/archive/2010/06/10/don-t-repeat-yourself-consts-are-already-static.aspx para obtener más ideas sobre este tipo de problemas.
Podría ser implícito, pero también complicaría la lectura del código y conduciría a confusiones.
Porque, por definición, todos sus miembros deben ser estáticos. Decidieron no dar un confuso azúcar sintáctico.
Ricardo,
Hmmmm ... supongo que los diseñadores de idiomas decidieron que sería mejor ser muy, muy explícito ... para evitar cualquier posible confusión cuando un mantenedor, que no conoce el código , salta a la mitad de un clase estática, y supone que se encuentran en un contexto de instancia "normal".
Pero, por supuesto, eso es solo una suposición. La mayoría de los IDE te ayudan a salir de todos modos, agregando el modificador estático "automágicamente" ... o al menos destacando tu error en "tiempo de escritura", como apposed a "compilar tiempo".
Es una buena pregunta ... desafortunadamente no una con una respuesta "correcta" ... a menos que alguien pueda encontrar un enlace de un blog de C # -language-designers (o similar) discutiendo esta decisión. Lo que puedo decirle es: "apostaría $ 1,000 a que no es un accidente".
Aclamaciones. Keith.
Una razón por la que creo que es importante afirmar explícitamente que es estática es porque en un modelo de programación de subprocesos múltiples, estas variables estáticas son compartidas por múltiples hilos. Al hacer la revisión del código o el análisis del código, es mucho más fácil tomar esta importancia de leer la variable, en lugar de buscar la declaración de la clase, y determinar si las variables son estáticas o no estáticas. Puede ser bastante confuso cuando lee variables durante la revisión del código si no sabe si la clase es estática o no estática.
La codificación explícita hace las cosas mantenibles
Si quiero copiar un método de una clase a otra, para que el código esté mejor organizado, entonces tendría que seguir grabando muchas cosas todo el tiempo, solo en caso de que la clase de destino sea o no estática.
Al declarar al miembro como estático, también tiene una indicación visual de lo que es el código cuando lo ve.
También es menos confuso . Imagine una clase que es estática, y dentro de ella tiene los miembros marcados como estáticos y otros no marcados.
Puedo ver muchas razones, y existen muchas otras razones.