C# protette settore privato, aggiungere proprietà--perché?

Question

In Visual Studio 2008 Team System, ho appena eseguito l'Analisi del Codice (da Analizzare menu) su uno dei miei progetti di C#.Una delle avvertenze prodotto è stato il seguente:

Microsoft.Design :Perché il campo 'di Connessione._domain' è visibile al di fuori della sua dichiarazione di tipo, di cambiare la sua accessibilità per privati e aggiungere una proprietà, con la stessa accessibilità come il campo ha attualmente, per fornire l'accesso ad esso.

Si riferisce il seguente campo:

public abstract class Connection
{
    protected string _domain;
}

Non riesco a capire il ragionamento dietro il suggerimento.Questo è quello che penso che mi vuole fare:

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

Due domande:

1. Non ho capito bene cosa il suggerimento che mi vuole fare, codice-saggio?
2. Perché mi vuoi fare questo?

Answer 1

Sì, penso che hai capito bene - anche se nelle versioni successive di C#, non c'è modo più conciso per scrivere:

public string Domain { get; set; }

Perché?È tutto su di incapsulamento.Se si fa come suggerisce il nome stesso, è possibile in seguito modificare la definizione del Dominio di proprietà senza influenzare la chiamata di codice che utilizza la proprietà.Poiché la classe è pubblico, e teoricamente potrebbe essere chiamato da codice che non lo hai scritto, che è potenzialmente molto importante.

Answer 2

Yep.Questo è il suggerimento.Non dovreste avere alcun accessibilità maggiore rispetto a privato esposto come diretta campi di istanza.

È uno dei principali principi di ALLUVIONI incapsulamento indicato anche come dati "nascondere".

Answer 3

1. Sì, hai corretto il problema del codice di saggio.
2. Si tratta di circa incapsulamento. _domain sono i dati circa il vostro oggetto.Invece di esporre direttamente in modo che ogni cliente ha accesso non filtrato, è necessario fornire un'interfaccia per il loro accesso.Praticamente questo potrebbe essere l'aggiunta di convalida per setter in modo che non può essere impostato su qualsiasi valore.Potrebbe sembrare stupido, se tu sei l'unico che la scrittura di codice, perché si sa come funziona l'API.Ma provate a pensare le cose in grande, a livello aziendale, è meglio avere un'API in modo che l'oggetto può essere visto come una scatola che accomiplishes un compito.Si potrebbe dire che lei non potrà mai avere la necessità di aggiungere qualcosa come convalida di tale oggetto, ma le cose sono fatte in quel modo per tenere la possibilità di farlo, e anche per essere coerenti.

Answer 4

La tua traduzione è corretta.Lo stesso discorso può essere fatto per l'uso di 'protetto' proprietà può essere fatta per l'uso di 'pubblico' proprietà invece di esporre le variabili membro direttamente.

Se questo porta solo a una proliferazione di semplice getter e setter quindi penso che il danno al codice readablity supera il vantaggio di essere in grado di modificare il codice in futuro.Con lo sviluppo di generato dal compilatore proprietà in C# questo non è così male, basta usare:

protected string Domain { get; set; }

Answer 5

Questo perché se avete sempre voluto modificare il campo a una proprietà, in futuro, si potrebbe rompere qualsiasi altro assembly che dipendono da esso.

È buona norma conservare tutti i settori privati e avvolgerli in proprietà, in modo che si ha la possibilità di aggiungere la convalida o altra logica, in futuro, senza dover ricompilare tutti i consumatori (o in questo caso gli eredi) della classe.

Answer 6

In risposta alla tua domanda...sì.

Tuttavia, vorrei solo usare l'auto-sintassi della proprietà:

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

Answer 7

Fondamentalmente, la proprietà di fornire più di restituzione o l'impostazione di un membro.Essi consentono di aggiungere la logica che si potrebbe verificare un corretto formato di input, gamma di validazione, etc.

La risposta selezionata dal link mette di più, "Proprietà" e di fornire l'incapsulamento.È possibile encapulate alcun bisogno di convalida/formattazione/conversione in codice per la proprietà.Questo sarebbe difficile da fare per i campi."

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

Answer 8

In aggiunta alle altre risposte qui citate, public/membri protetti che iniziano con un carattere di sottolineatura, non sono CLS, che non vi è alcun obbligo per .NET lingue per aiutare i soci con i principali caratteri di sottolineatura, in modo da qualcuno che eredita dalla classe in un altro .NET lingua potrebbe non essere in grado di accedere a quel particolare membro protetto.

So che probabilmente non si applicano a voi, ma potrebbe essere parte del motivo per l'analisi del codice di avviso.