605 votos

Cuándo utilizar las clases estáticas en C#

He aquí lo MSDN tiene que decir en virtud de Cuándo Usar las Clases Estáticas:

static class CompanyInfo
{
    public static string GetCompanyName() { return "CompanyName"; }
    public static string GetCompanyAddress() { return "CompanyAddress"; }
    //...
}

El uso de una clase estática como de una unidad de organización de los métodos no asociados con determinados objetos. También, una clase estática puede hacer que su la aplicación más sencilla y rápida porque usted no tiene que crear un objeto, en el fin de llamar a sus métodos. Es útil para organizar los métodos de dentro de la clase de una manera significativa, tal como en los métodos de la clase Math en el espacio de nombres System.

Para mí, ese ejemplo no parece muy muchos posibles escenarios de uso para las clases estáticas. En el pasado he utilizado las clases estáticas para apátridas suites de funciones relacionadas, pero de eso se trata. Así, bajo qué circunstancias debe (y no debe) una clase de ser declarada static?

717voto

Mark S. Rasmussen Puntos 13313

Escribí mis pensamientos de las clases estáticas en un anterior hilo:
http://stackoverflow.com/questions/205689/class-with-single-method-best-approach#206481

Me encantaba la utilidad de las clases de lleno con métodos estáticos. Ellos hicieron un gran consolidación de métodos auxiliares que de otra manera se encuentran alrededor causando redundancia y mantenimiento infierno. Es muy fácil de usar, sin que la creación de instancias, sin eliminación, sólo fuego n''forget. Supongo que este fue mi primer inconsciente intento de crear una arquitectura orientada a servicios - muchos de los apátridas de los servicios que sólo hizo su trabajo y nada más. Como un sistema crece, sin embargo, los dragones.

Polimorfismo

Dicen que tenemos el método UtilityClass.SomeMethod que felizmente zumbidos a lo largo. De repente tenemos que cambiar la funcionalidad ligeramente. La mayoría de la funcionalidad es la misma, pero tenemos que cambiar un par de piezas, no obstante. De no haber sido un método estático, se podría hacer un derivado de la clase y cambiar el método de contenido según sea necesario. Como se trata de un método estático, no se puede. Claro, si sólo tenemos que añadir la funcionalidad, ya sea antes o después de que el antiguo método, podemos crear una nueva clase y llamar a la vieja dentro de ella - sino que simplemente asqueroso.

Interfaz de males

Los métodos estáticos no pueden ser definidos a través de interfaces para la lógica razones. Y ya que no podemos reemplazar los métodos estáticos, las clases estáticas son inútiles cuando tenemos que pasar todo por su interfaz. Esto hace que seamos incapaces de utilizar las clases estáticas como parte de una estrategia de patrón. Podríamos parche de algunos de los problemas por los que pasa delegados en lugar de interfaces.

De prueba

Básicamente, esto va de la mano con la interfaz de males mencionados anteriormente. Como nuestra capacidad de intercambio de las implementaciones es muy limitado, también vamos a tener problemas para sustituir el código de producción con un código de prueba. De nuevo, podemos envolver a ellos sino que nos obligan a cambiar gran parte de nuestro código sólo para ser capaz de aceptar contenedores en lugar de los objetos reales.

Fomenta blobs

Como métodos estáticos son generalmente utilizados como métodos de utilidad y la utilidad de los métodos usualmente tienen diferentes propósitos, nos daremos cuenta enseguida de terminar con una gran clase se llenó de no-coherente de funcionalidad - idealmente, cada clase debe tener un propósito único dentro del sistema. Yo preferiría mucho más que un cinco veces las clases, así como sus efectos están bien definidos.

Parámetro de fluencia

Para empezar, que poco lindos e inocentes método estático puede tomar de un solo parámetro. Como en la funcionalidad, crece, un par de nuevos parámetros se agregan. Pronto otros parámetros añadió que son opcionales, así que vamos a crear sobrecargas del método (o simplemente añadir los valores por defecto, en las lenguas que los apoyan). Antes de mucho tiempo, tenemos un método que toma 10 parámetros. Sólo las tres primeras son realmente necesarios, los parámetros de 4 a 7 son opcionales. Pero si el parámetro 6 se especifica, 7-9 están obligados a rellenar así... Tenía que hemos creado una clase con el único propósito de hacer lo que este método estático hizo, podríamos resolver esto mediante la adopción de los parámetros necesarios en el constructor, y que permite al usuario establecer opcional de valores a través de las propiedades o métodos para establecer múltiples interdependientes valores al mismo tiempo. También, si un método ha crecido a esta suma de complejidad, lo más probable es que necesita estar en su propia clase de todos modos.

Los consumidores más exigentes para crear una instancia de las clases sin razón

Uno de los argumentos más comunes es, ¿por qué la demanda que los consumidores de nuestra clase de crear una instancia para la invocación de este método único, mientras no se utilice para la instancia después? La creación de una instancia de una clase es una muy, muy barato operación en la mayoría de los idiomas, por lo que la velocidad no es un problema. Agregar una línea de código adicional para el consumidor es un bajo costo para sentar las bases de una forma mucho más fácil de mantener la solución en el futuro. Y por último, si se desea evitar la creación de instancias, simplemente crear un singleton contenedor de su clase que permite una fácil reutilización - aunque esto hace que el requisito de que su clase es apátrida. Si no es apátrida, todavía puede crear estática métodos de contenedor que se encargan de todo, mientras que proporciona todos los beneficios en el largo plazo. Por último, también puedes hacer una clase que oculta la creación de instancias como si de un singleton: MyWrapper.Instance es una propiedad que sólo devuelve new MyClass();

Sólo un Sith ofertas de hoteles en absolutos

Por supuesto, hay excepciones a mi aversión a los métodos estáticos. La verdadera utilidad de las clases que no suponen ningún riesgo para la hinchazón son excelentes casos de métodos estáticos Espacios como un ejemplo. Si su proyecto es un one-off con la ausencia de requisitos para el futuro mantenimiento, en general, la arquitectura realmente no es muy importante - estática o no estática, no importa - desarrollo de la velocidad, sin embargo.

Normas, normas, normas!

El uso de métodos de instancia no inhibe también el uso de métodos estáticos, y viceversa. En la medida en que el razonamiento detrás de la diferenciación y estandarizados. No hay nada peor que mirar por encima de una capa de negocio en expansión con diferentes métodos de aplicación.

147voto

Despertar Puntos 5365

A la hora de decidir si hacer una clase estática o no estático, usted necesita observar lo que la información que usted está tratando de representar. Esto implica una más 'bottom-up' de estilo de programación en centrarse en los datos que se representan en primer lugar. Es la clase que usted está escribiendo un objeto del mundo real como una roca, o una silla? Estas cosas son de tipo físico y tienen atributos físicos tales como el color, el peso, que le dice que puede que desee crear instancias de varios objetos con propiedades diferentes. Puede que desee un negro silla Y una silla roja al mismo tiempo. Si alguna vez necesita dos configuraciones al mismo tiempo, inmediatamente sabemos que se quiere instanciar un objeto de modo que cada objeto puede ser único y existir al mismo tiempo.

En el otro extremo, las funciones estáticas tienden a prestar más dinero a acciones que no pertenecen a un objeto del mundo real o de un objeto que se puede representar fácilmente. Recuerde que C#'s predecesores son C++ y C, donde usted puede definir global de las funciones que no existen en una clase. Esto se presta más para el 'top-down' de la programación. Los métodos estáticos pueden ser utilizados para estos casos, donde no tiene sentido que un " objeto " realiza la tarea. Obligando a utilizar las clases de esto sólo hace que sea más fácil de grupo relacionadas con la funcionalidad que le ayuda a crear código más mantenible.

La mayoría de las clases puede ser representado por cualquiera de las estático o no estático, pero cuando estás en duda en regresar a su OOP raíces y tratar de pensar acerca de lo que usted representa. Es este un objeto que está llevando a cabo una acción (un coche que puede acelerar, frenar, girar) o algo más abstracto (como la visualización de la salida).

Ponte en contacto con tu interior OOP y usted nunca puede ir mal!

35voto

Mark Cidade Puntos 53945

Para C# 3.0, métodos de extensión sólo pueden existir en las clases estáticas de alto nivel.

24voto

user25306 Puntos 185

Si utiliza herramientas de análisis de código (ex: fxcop) recomendará que haces tu método estático si no acceder a los datos de la instancia. La justificación es que hay una ganancia de perf. Ref: http://msdn.microsoft.com/en-us/library/ms245046(VS.80).aspx.

más de una regla, y luego una pauta muy...

12voto

Rob Puntos 1092

Tiendo a utilizar las clases estáticas para las fábricas. Por ejemplo, esta es la clase de registro en uno de mis proyectos:

public static class Log
{
   private static readonly ILoggerFactory _loggerFactory =
      IoC.Resolve<ILoggerFactory>();

   public static ILogger For<T>(T instance)
   {
      return For(typeof(T));
   }

   public static ILogger For(Type type)
   {
      return _loggerFactory.GetLoggerFor(type);
   }
}

Usted puede haber notado incluso que el COI se llama con un descriptor de acceso estático. La mayoría de las veces para mí, si se puede llamar a métodos estáticos en una clase, eso es todo lo que puede hacer para que me marca la clase como estáticos para más claridad.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X