C# campo protetto a privato, aggiungere proprietà - perché?

Question

In Visual Studio 2008 Team System, ho appena eseguito Analisi codice (dal menu Analizza) in uno dei miei progetti C#. Una delle avvertenze prodotte è stata la seguente:

Microsoft.Design: Perché campo 'Connection._domain' è visibile al di fuori del suo tipo dichiarando, cambiare la sua accessibilità a privati ​​e aggiungere una proprietà, con la stessa accessibilità come la campo ha attualmente, per fornire l'accesso ad esso.

E 'riferendosi al seguente campo:

public abstract class Connection 
{ 
    protected string _domain; 
} 

Non capisco il ragionamento dietro il suggerimento. Questo è ciò che penso che vuole che io faccia:

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

Due domande:

1. Ho capito bene che cosa il suggerimento vuole che io faccia, il codice-saggio?
2. Perché mi vuole fare questo?

Answer 1

Sì, credo di aver capito correttamente - anche se in versioni successive di C#, c'è un modo più conciso di scriverlo:

public string Domain { get; set; } 

Perché? Si tratta di incapsulamento. Se si fa come suggerisce, è possibile modificare in seguito la definizione della proprietà Dominio senza influire su alcun codice di chiamata che utilizza tale proprietà. Dal momento che la tua classe è pubblica e potrebbe essere chiamata per codice che non hai scritto, è potenzialmente abbastanza importante.

Answer 2

Sì. Questo è il suggerimento. Non dovresti avere accessibilità superiore a quella privata esposta come campi di istanze dirette.

È uno dei principi principali di OOD - l'incapsulamento indicato anche come "nascondiglio dei dati".

Answer 3

1. Sì, hai corretto il codice problema.
2. Riguarda l'incapsulamento. _domain sono dati sul tuo oggetto. Piuttosto esponendolo direttamente in modo che ogni client abbia accesso non filtrato, è necessario fornire un'interfaccia per accedervi. In pratica, questo potrebbe aggiungere la convalida al setter in modo che non possa essere impostato su alcun valore. Potrebbe sembrare sciocco se tu sei l'unico codice di scrittura perché sai come funziona la tua API. Ma prova a pensare a cose a livello aziendale di grandi dimensioni, è meglio avere un'API in modo che il tuo oggetto possa essere visto come una scatola che accompagna un compito. Potresti dire che non avrai mai bisogno di aggiungere qualcosa come la validazione a quell'oggetto, ma le cose sono fatte in quel modo per tenerne conto e anche per essere coerenti.

Answer 4

Questo perché se si desidera modificare il campo in una proprietà in futuro si interromperà qualsiasi altro assembly che dipende da esso.

È buona prassi mantenere tutti i campi privati ​​e avvolgerli nelle proprietà in modo da avere la possibilità di aggiungere la convalida o altra logica in futuro senza ricompilare tutti gli utenti (o in questo caso gli eredi) della classe.

Answer 5

La tua traduzione è corretta.Lo stesso argomento per può essere fatto per utilizzare le proprietà 'protette', come può essere fatto per utilizzare le proprietà 'pubblici', invece di esporre direttamente le variabili membro.

Se questo porta solo a una proliferazione di semplici getter e setter, allora penso che il danno alla readablità del codice superi il vantaggio di poter cambiare il codice in futuro. Con lo sviluppo di proprietà generati dal compilatore in C# questo non è poi così male, basta usare:

protected string Domain { get; set; } 

Answer 6

In risposta alla tua domanda ... sì.

Tuttavia, vorrei solo usare la sintassi auto-immobile:

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

Answer 7

In sostanza, le proprietà forniscono più di ritorno o l'impostazione di un membro. Essi consentono di aggiungere una logica che potrebbe verificare un formato di input, una convalida dell'intervallo, ecc.

La risposta selezionata dal collegamento la mette meglio, "Le proprietà forniscono l'incapsulamento.È possibile racchiudere qualsiasi convalida/formulazione/conversione necessaria nel codice per la proprietà, 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 menzionati,/membri pubblici protetti che iniziano con un carattere di sottolineatura non sono CLS-compliant, nel senso che non v'è alcun obbligo per linguaggi .NET per sostenere i membri con importanti sottolineature, in modo da qualcuno l'ereditarietà della tua classe in una diversa lingua .NET potrebbe non essere in grado di accedere a quel particolare membro protetto.

lo so, probabilmente non si applica a voi, ma potrebbe essere una delle ragioni per l'avvertimento analisi del codice.