C# protegidos campo privado, adicione a propriedade--por quê?

Question

No Visual Studio 2008 Team System, eu corri de Análise de Código (no menu Analyze) em um dos meus projetos C#.Um dos avisos produzido foi o seguinte:

A Microsoft.Design :Porque o campo 'Conexão._domain' é visível do lado de fora de sua declarando tipo, alterar a sua acessibilidade a privada e adicionar uma propriedade, com a mesma acessibilidade como o campo tem atualmente, para fornecer acesso a ele.

Ele está a referir-se para o campo a seguir:

public abstract class Connection
{
    protected string _domain;
}

Eu não consigo entender o raciocínio por trás da sugestão.Isso é o que eu acho que ele quer que eu faça:

public abstract class Connection
{
    private string _domain;
    protected string Domain { get { return _domain; } set { _domain = value; } }
}

Duas perguntas:

1. Que eu me fiz entender corretamente o que a sugestão quer que eu faça, código-sábio?
2. Por que ele quer que eu faça isso?

Answer 1

Sim, acho que você entendeu corretamente - embora em versões posteriores de C#, existe uma maneira mais concisa de escrevê -lo:

public string Domain { get; set; }

Por quê? É tudo sobre encapsulamento. Se você o fizer o que sugerir, poderá alterar posteriormente a definição da propriedade de domínio sem afetar nenhum código de chamada que use essa propriedade. Como sua classe é pública e pode ser chamada pelo código que você não escreveu, isso é potencialmente muito importante.

Answer 2

Sim. Essa é a sugestão. Você não deve ter nenhuma acessibilidade superior ao privado exposto como campos de instância direta.

É um dos principais princípios do OOD - o encapsulamento também chamado de 'Hiding Data -Hiding'.

Answer 3

1. Sim, você corrigiu o código do problema.
2. É sobre encapsulamento. _domain são dados sobre seu objeto. Em vez de expor diretamente para que qualquer cliente tenha acesso não filtrado, você deve fornecer uma interface para eles acessá -lo. Praticamente isso pode estar adicionando validação ao setter para que ele não possa ser definido como qualquer valor. Pode parecer bobo se você é o único código de escrita porque sabe como sua API funciona. Mas tente pensar nas coisas em um grande nível de empresa, é melhor ter uma API para que seu objeto possa ser visto como uma caixa que acompanha uma tarefa. Você pode dizer que nunca terá a necessidade de adicionar algo como validação a esse objeto, mas as coisas são feitas dessa maneira a manter a possibilidade e também para serem consistentes.

Answer 4

Sua tradução está correta.O mesmo argumento pode ser feito usando 'protegido' propriedades como pode ser feito usando 'público' propriedades em vez de expor-membro variáveis diretamente.

Se isso só leva a uma proliferação de simples getters e setters, em seguida, eu acho que o dano ao código readablity supera a vantagem de ser capaz de alterar o código no futuro.Com o desenvolvimento do compilador gerado propriedades no C# isso não é tão ruim, basta usar:

protected string Domain { get; set; }

Answer 5

Isso ocorre porque, se você quisesse mudar o campo para uma propriedade no futuro, quebraria outras assembléias que dependem dele.

É uma boa prática manter todos os campos privados e envolvê -los em propriedades, para que você tenha a opção de adicionar validação ou outra lógica no futuro sem recompilar todos os consumidores (ou neste caso herdeiros) da sua classe.

Answer 6

Em resposta à sua pergunta ... sim.

No entanto, eu apenas usaria a sintaxe de propriedade automática:

public abstract class Connection
{
    protected string Domain { get; set; }
}

Answer 7

Basicamente, as propriedades fornecem mais do que devolver ou definir um membro. Eles permitem que você adicione lógica que possa verificar um formato de entrada adequado, validação de faixa, etc.

A resposta selecionada do link coloca melhor: "As propriedades fornecem encapsulamento. Você pode encapsular qualquer validação/formação/conversão necessária no código da propriedade. Isso seria difícil de fazer para os campos".

http://social.msdn.microsoft.com/forums/en-ie/netfxbcl/thread/985f4887-92ae-4ec2-b2-b7ae-ec8cc6eb3a42

Answer 8

Além das outras respostas mencionadas aqui, membros públicos/protegidos que começam com um sublinhado não são Compatível com CLS, na medida em que não há exigência de que os idiomas .NET apoiem os membros com os principais sublinhados, portanto, alguém herdando de sua classe em um idioma .NET diferente pode não ser capaz de acessar esse membro protegido em particular.

Eu sei, provavelmente não se aplica a você, mas pode fazer parte do motivo do aviso de análise de código.