Quando usar classes estáticas em C # [duplicado]

StackOverflow https://stackoverflow.com/questions/241339

  •  04-07-2019
  •  | 
  •  

Pergunta

Esta questão já tem uma resposta aqui:

Aqui está o que MSDN tem a dizer em Quando classes de uso estático : 

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

Use uma classe estática como uma unidade de organização de métodos não associado com objectos particulares. Além disso, uma classe estática pode fazer o seu implementação mais simples e mais rápido porque você não tem que criar uma objeto, a fim de chamar seus métodos. É útil para organizar os métodos dentro da classe de uma forma significativa, tais como os métodos da classe Math no namespace System.

Para mim, esse exemplo não parece cobrir muitos cenários de uso possíveis para classes estáticas. No passado, eu usei classes estáticas para suites apátridas de funções relacionadas, mas que é sobre ele. Então, em que circunstâncias deve (e não deve) uma classe ser declarada estática?

Foi útil?

Solução

Eu escrevi meus pensamentos de classes estáticas numa resposta anterior Stack Overflow: classe com um método único -? Melhor abordagem

Eu costumava classes de utilitários amor preenchidos com métodos estáticos. Eles fizeram uma grande consolidação dos métodos auxiliares que de outra forma se encontram ao redor causando redundância e manutenção inferno. Eles são muito fáceis de usar, não instanciação, nenhuma disposição, apenas fire'n'forget. Eu acho que esta foi a minha primeira tentativa inconsciente na criação de uma arquitetura orientada a serviços - lotes de serviços apátridas que apenas fez o seu trabalho e nada mais. Como um sistema cresce no entanto, dragões estar chegando.

Polimorfismo

dizer que temos o método UtilityClass.SomeMethod que felizmente vibra junto. De repente, é preciso mudar a funcionalidade ligeiramente. A maioria das funcionalidades é a mesma, mas nós temos que mudar um par de peças, no entanto. Se não fosse um método estático, podemos fazer uma classe derivada e alterar o conteúdo do método, conforme necessário. Como é um método estático, não podemos. Claro, se nós só precisa adicionar funcionalidade antes ou após o método antigo, podemos criar uma nova classe e chamar o antigo dentro dele - mas isso é apenas bruto

.

Interface problemas

Os métodos estáticos não pode ser definida por meio de interfaces por razões lógicas. E uma vez que não é possível substituir métodos estáticos, classes estáticas são inúteis quando precisamos passá-los em torno de sua interface. Isso nos torna incapazes de usar classes estáticas como parte de um padrão de estratégia. Podemos corrigir alguns problemas por passando delegados em vez de interfaces .

Teste

Isso basicamente anda de mãos dadas com os problemas de interface mencionados acima. Como nossa capacidade de implementações intercambiando é muito limitado, nós também terá problemas substituindo o código de produção com código de teste. Mais uma vez, podemos envolvê-los, mas vai nos obrigar a mudar grandes partes do nosso código apenas para ser capaz de aceitar wrappers em vez dos objetos reais.

Fosters blobs

Como métodos estáticos são geralmente utilizados como métodos de utilitário e métodos utilitários geralmente têm finalidades diferentes, vamos rapidamente acabar com uma grande classe encheu-se com a funcionalidade não coerente - de preferência, cada classe deve ter um único propósito dentro do sistema. Eu prefiro ter um cinco vezes as classes, desde que seus propósitos são bem definidas.

Parâmetro fluência

Para começar, esse método estático bonito e inocente pode tomar um único parâmetro. Como funcionalidade cresce, um par de novos parâmetros são adicionados. Logo outros parâmetros são adicionados que são opcionais, por isso criamos sobrecargas do método (ou apenas adicionar valores padrão, em idiomas que os apoiam). Em pouco tempo, temos um método que leva 10 parâmetros. Apenas os três primeiros são realmente necessários, parâmetros 4-7 são opcionais. Mas se o parâmetro 6 é especificado, 7-9 são necessários para ser preenchido, bem ... Se tivéssemos criado uma classe com o único propósito de fazer o que este método estático fez, nós poderia resolver isso tomando os parâmetros necessários no construtor, e permitindo que o utilizador a valores opcionais conjunto através de propriedades, ou métodos para definir vários valores interdependentes ao mesmo tempo. Além disso, se um método tem crescido para essa quantidade de complexidade, necessidades com maior probabilidade de estar em sua própria classe de qualquer maneira.

consumidores exigentes para criar uma instância de aulas sem razão

Um dos mais argumentos comuns é: Por que demanda que os consumidores de nossa classe criar uma instância para chamar esse método único, ao não ter nenhum uso para a instância depois? Criando uma instância de uma classe é uma operação muito, muito barato ema maioria dos idiomas, velocidade, portanto, não é um problema. Adicionando uma linha extra de código para o consumidor é um baixo custo para lançar as bases de uma solução muito mais sustentável no futuro. E, finalmente, se você quer evitar a criação de instâncias, basta criar um invólucro de singleton de sua classe que permite a fácil reutilização - embora isso faz a exigência de que sua classe é apátrida. Se não for apátrida, você ainda pode criar métodos de mensagens publicitárias estáticas que lidam com tudo, enquanto ainda dando-lhe todos os benefícios a longo prazo. Finalmente, você também pode fazer uma classe que esconde a instanciação como se fosse um singleton: MyWrapper.Instance é uma propriedade que retorna apenas new MyClass();

Apenas um Sith ofertas em absolutos

Claro, há exceções a minha antipatia de métodos estáticos. classes de utilitários verdadeiros que não representam qualquer risco para o inchaço são excelentes casos de métodos estáticos - System.Convert como um exemplo. Se o seu projecto é um one-off sem requisitos de manutenção futura, a arquitetura geral realmente não é muito importante - estática ou não estática, realmente não importa -. Velocidade de desenvolvimento faz, no entanto

Padrões, normas, padrões!

Usando métodos de instância não inibe você de também usar métodos estáticos, e vice-versa. Enquanto há raciocínio por trás da diferenciação e é padronizado. Não há nada pior do que olhar sobre uma camada de negócios em expansão com diferentes métodos de execução.

Outras dicas

Ao decidir se a fazer uma classe estática ou não estática você precisa olhar para o que informação que você está tentando representar. Isto implica um ' bottom-up' estilo mais de programação, onde você se concentrar sobre os dados que você está representando pela primeira vez. É a classe que você está escrevendo um objeto do mundo real como uma rocha ou uma cadeira? Essas coisas são física e têm atributos físicos, tais como cor, peso, que lhe diz que você pode querer instanciar vários objetos com propriedades diferentes. Eu posso querer uma cadeira preta e uma cadeira vermelha, ao mesmo tempo. Se você precisar de duas configurações ao mesmo tempo, então você instantaneamente sabe que você vai querer instanciar-lo como um objeto para cada objeto pode ser única e existir ao mesmo tempo.

No outro extremo, funções estáticas tendem a emprestar mais a ações que não pertencem a um objeto do mundo real ou um objeto que você pode facilmente representar. Lembre-se que antecessores C # 's são C ++ e C onde você pode apenas definir funções globais que não existem em uma classe. Isso dá mais para ' top-down ' programação. Os métodos estáticos pode ser usada para esses casos em que não faz sentido que um executa 'objeto' a tarefa. Ao forçar você a usar classes isso só torna mais fácil para agrupar funcionalidades relacionadas que ajuda a criar código mais sustentável.

A maioria das classes pode ser representado por estática ou não estática, mas quando você estiver em dúvida apenas voltar para suas raízes OOP e tentar pensar sobre o que você está representando. É este um objeto que está realizando uma ação (um carro que pode acelerar, desacelerar, por sua vez) ou algo mais abstrato (como a exibição de saída).

Entre em contato com seu OOP interior e você nunca pode dar errado!

Para C # 3.0, os métodos de extensão só podem existir em classes estáticas de nível superior.

Se você usar ferramentas de análise de código (por exemplo FxCop ), ele irá recomendar que você marcar um static método se esse método não faça dados de instância de acesso. A lógica é que há um ganho de desempenho. MSDN:. CA1822 - membros Marcar como estática

É mais de uma diretriz do que uma regra, realmente ...

Eu tendem a usar classes estáticas para as fábricas. Por exemplo, esta é a classe de log em um dos meus projetos: 

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);
   }
}

Você pode ter notado que IoC é chamado com um acessor estática. A maioria do tempo para mim, se você pode chamar métodos estáticos em uma classe, isso é tudo que você pode fazer para que eu marcar a classe como estáticos para maior clareza extra.

aulas

estáticas são muito útil e ter um lugar, por exemplo, bibliotecas.

O melhor exemplo que posso dar é a classe .Net Math, uma classe estática namespace System que contém uma biblioteca de funções matemáticas.

É como qualquer outra coisa, use a ferramenta certa para o trabalho, e se não tudo pode ser abusado.

inexpressivamente descartando classes estáticas como errado, não usá-los, ou dizendo "só pode haver um" ou nenhum, é tão errado quanto ao longo usando a eles.

C # .Net contém um número de classes estáticas que é usos como a classe Math.

Assim, dada a correta implementação são tremendamente útil.

Nós temos uma classe TimeZone estática que contém uma série de funções de fuso horário negócios relacionados, não há necessidade de criar várias instâncias da classe tanto com a classe Math contém um conjunto de TimeZone realated funções globalmente accesible (métodos) em uma classe estática.

eu comecei a usar classes estáticas quando eu quiser usar funções, ao invés de aulas, como minha unidade de reutilização. Anteriormente, eu era tudo sobre o mal de classes estáticas. No entanto, aprender F # fez-me vê-los sob uma nova luz.

O que quero dizer com isto? Bem, dizem que quando se trabalha-se alguns super href="http://en.wikipedia.org/wiki/Don%27t_repeat_yourself" rel="nofollow">, eu acabar com um monte de um aulas -method. I pode apenas puxar esses métodos em uma classe estática e depois injetá-las em dependências usando um delegado. Isso também funciona muito bem com o meu injeção de dependência (DI) recipiente de escolha Autofac.

De tomando curso uma dependência direta em um método estático ainda é normalmente mal (há alguns usos não-malignas).

Eu uso classes estáticas como um meio para definir "funcionalidade extra" que um objeto de um determinado tipo poderia usar em um contexto específico. Normalmente, eles acabam por ser as classes de utilitário.

Além disso, eu acho que "Use uma classe estática como uma unidade de organização para métodos não associados com objetos particulares." descrever muito bem o seu uso pretendido.

Esta é uma outra questão antiga, mas muito quente desde OOP chutou. Há muitas razões para usar (ou não) uma classe estática, é claro ea maioria deles foram cobertos na multidão de respostas.

Vou apenas acrescentar os meus 2 centavos para isso, dizendo que, eu faço uma classe estática, quando esta classe é algo que seria única no sistema e que realmente não faz sentido ter quaisquer instâncias dele no programa . No entanto, I reservar este uso para grandes classes. Eu nunca declarar tais classes pequenas, como no exemplo MSDN como "estática" e, certamente, não classes que vão ser membros de outras classes.

Eu também gostaria de observar que estática métodos e estáticos aulas são duas coisas diferentes a considerar. As principais desvantagens mencionadas na resposta aceitos são de estática métodos . estática aulas oferecer a mesma flexibilidade que as classes normais (onde as propriedades e parâmetros estão em causa), e todos os métodos usados ??neles deve ser relevante para o propósito da existência da classe.

Um bom exemplo, na minha opinião, de um candidato para uma classe estática é uma classe "FileProcessing", que conteria todos os métodos e propriedades relevantes para vários objetos do programa para executar operações FileProcessing complexos. Ele quase não tem qualquer significado para ter mais de uma instância dessa classe e ser estática irá torná-lo prontamente disponível a tudo em seu programa.

Eu só uso classes estáticas para métodos auxiliares, mas com o advento do C # 3.0, eu prefiro usar métodos de extensão para aqueles.

Eu raramente usar classes métodos estáticos para as mesmas razões pelas quais eu raramente usam o "padrão de design" singleton.

Com base MSDN :

  1. Você não pode criar a instância de classes estáticas
  2. Se a classe declarada como estática, variável de membro deve ser estática para essa classe
  3. Sealed [não pode ser herdada]
  4. não pode contém Instância construtor
  5. Gerenciamento de memória

Exemplo: cálculos matemáticos (valores de matemática) não muda [PADRÃO DE CÁLCULO PARA valores definidos]

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top