Está tendo constantes públicas "ruins"?

36

Isso é:

public MyClass
{
    public const string SomeString = "SomeValue";
}

pior que isso:

public MyClass
{
    public static string SomeString { get{ return "SomeValue";}}
}

Ambos podem ser referenciados da mesma maneira:

if (someString == MyClass.SomeString)
     ...
O segundo, no entanto, tem a proteção de ser uma propriedade. Mas quanto melhor é isso do que um const?

Eu aprendi mais e mais os perigos de ter campos públicos. Então, quando vi algum código usando essas constantes em campos públicos, imediatamente comecei a refatorá-las para as propriedades. Mas, no meio do caminho, comecei a me perguntar qual seria o benefício de ter as propriedades estáticas sobre as constantes.

Alguma idéia?

    
por Vaccano 31.01.2012 / 21:32
fonte

4 respostas

54

Em C # é muito ruim por nenhuma das razões mencionadas neste tópico.

As constantes públicas em C # são criadas em assemblies de referência. Ou seja, se você tiver um SomeOtherClass em um assembly separado referenciando SomeString em MyClass, o CIL gerado para SomeOtherClass conterá uma string "SomeValue" codificada.

Se você for reimplantar a dll que contém MyClass, mas não SomeOtherClass e alterar a const, SomeOtherClass não conterá o que você acha que irá - ela conterá o valor original.

Se você é 100% positivo, é uma constante universal como o Pi, enlouquecer; caso contrário, com cuidado.

Esta é uma explicação melhor: link

    
por 31.01.2012 / 22:18
fonte
20

A alteração de um campo em uma propriedade é uma quebra de alteração. Você perde a compatibilidade com binário, fonte e reflexão.

Além disso:

  • There's more fine-grained access control with properties. Need it to be publicly gettable but really only want it set with protected access? No problem (from C# 2 onwards, at least).
  • Want to break into the debugger whenever the value changes? Just add a breakpoint in the setter.
  • Want to log all access? Just add logging to the getter.
  • Properties are used for data binding; fields aren't.

link

Tudo o que disse, não vejo como as constantes são realmente afetadas por isso (especialmente se você não precisa de nenhum dos recursos acima), a menos que sua API mude de tal forma que elas não sejam mais constantes. / p>     

por 31.01.2012 / 21:44
fonte
11

Os perigos dos campos públicos estão no fato de que eles são mutáveis e que a implementação subjacente a eles está sujeita a mudanças.

Quando se trata de um const , isso normalmente não é um problema (da mesma forma que as enumerações públicas) - a menos que você ache que const será mutável e que você precisará de encapsulamento em algum momento ( dizer para registrar quantas vezes ele foi pesquisado), você deve mantê-lo como um public const .

    
por 31.01.2012 / 21:36
fonte
1

Uma constante é dados. Propriedades implicam a possibilidade de comportamento quando você tanto "olha" para o valor.

O comportamento de empacotamento (ou a sua possibilidade futura) com dados constantes está errado. Para a maioria dos sistemas, isso não importa, mas pode.

Digamos que o valor seja "PI" e usado extensivamente nos cálculos do sistema. Colocá-lo atrás das propriedades forçará os programadores clientes a programarem defensivamente. Eles devem atribuir o valor a uma constante duplicada. Se eles não enganarem, a próxima versão da biblioteca pode ter algum "comportamento" indesejado introduzido por trás da propriedade. O comportamento da propriedade (se estiver em uma biblioteca compilada) é desconhecido. Talvez ele tenha um bom desempenho no teste, mas pode haver códigos ocultos que sejam executados se uma condição especial for atendida. Esta não é uma otimização pré-madura. Especialmente para um sistema em tempo real em que a vida das pessoas depende.

Os programadores clientes podem até perder a segurança de uma constante, pois a linguagem pode não permitir que eles designem um valor de propriedade para sua constante duplicada.

Além disso, quando os programadores são forçados a atribuir o valor de sua propriedade à sua própria constante, eles efetivamente anulam qualquer comportamento que você espera realizar com sua propriedade.

Dados constantes verdadeiros não precisam nem precisam de encapsulamento.

    
por 01.02.2012 / 02:39
fonte

Tags