C # Feld an private geschützt, fügen Sie Eigenschaft - warum?

Question

In Visual Studio 2008 Team System, ich lief nur Code-Analyse (aus dem Menü Analyse) auf einem meines C # -Projekten. Einer der erzeugten Warnungen war die folgende:

  

Microsoft.Design. Weil Feld ‚Connection._domain‘ sichtbar außerhalb seines erklären Typ ist, den Zugang zu diesem privaten ändern und eine Eigenschaft, mit der gleichen Zugänglichkeit hinzufügen, um das Feld derzeit, den Zugriff darauf bieten

Es wird mit Bezug auf das folgende Feld:

public abstract class Connection
{
    protected string _domain;
}

Ich verstehe nicht, die Gründe für den Vorschlag. Dies ist, was ich denke, es will, dass ich tun:

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

Zwei Fragen:

1. Habe ich das richtig verstanden, was der Vorschlag von mir will, Code-weise?
2. Warum will es mir, dies zu tun?

Answer 1

Ja, ich glaube, Sie richtig verstanden - obwohl in späteren Versionen von C # gibt es eine prägnante Art und Weise, es zu schreiben:

public string Domain { get; set; }

Warum? Es ist alles über Verkapselung. Wenn Sie das tun, wie es schon sagt, können Sie später die Definition der ohne Domain-Eigenschaft ändern jeden anrufenden Code zu beeinflussen, dass diese Eigenschaft verwendet. Da Ihre Klasse öffentlich ist, und könnte möglicherweise durch Code aufgerufen werden, die Sie nicht schreiben, das ist potenziell sehr wichtig.

Answer 2

Ja. Das ist der Vorschlag. Sie sollten nicht Zugänglichkeit höher als die direkte Instanz Feldern ausgesetzt Privat haben.

Es ist eines der wichtigsten Prinzipien der OOD -. Verkapselung auch als ‚Daten-Versteck‘ genannt

Answer 3

1. Ja, Sie haben richtig das Problem Code weise.
2. Es geht um Kapselung. _domain sind Daten über das Objekt. Vielmehr dann direkt ausgesetzt wird, so dass jeder Kunde ungefilterten Zugang hat, sollten Sie eine Schnittstelle bereitstellen, für sie ist es zuzugreifen. Praktisch könnte dies die Validierung der Setter werden hinzugefügt, so dass es nicht auf einen beliebigen Wert eingestellt werden kann. Es könnte scheinen dumm, wenn Sie der einzige Code zu schreiben, weil Sie wissen, wie Ihre API funktioniert. Aber versuchen Sie über die Dinge auf einer großen Unternehmen Ebene zu denken, es besser ist, eine API zu haben, so dass das Objekt als ein Feld zu sehen, die eine Aufgabe accomiplishes. Man könnte sagen, Sie werden nie die Notwendigkeit, das Objekt so etwas wie Validierung hinzufügen, aber die Dinge so gemacht für die Möglichkeit, es zu halten, und auch im Einklang zu sein.

Answer 4

Ihre Übersetzung ist korrekt. Das gleiche Argument für als für die Verwendung von ‚geschützten‘ Eigenschaften hergestellt werden kann, für die Verwendung von ‚öffentlichen‘ Eigenschaften hergestellt werden, anstatt Elementvariablen direkt ausgesetzt wird.

Wenn dies führt nur zu einer Verbreitung von einfachen Getter und Setter dann denke ich, um den Schaden zu Code Lesbarkeit des überwiegt den Vorteil in der Lage, den Code in der Zukunft zu ändern. Mit der Entwicklung von Compiler generierten Eigenschaften in C # dies nicht ganz so schlecht ist, benutzen Sie einfach:

protected string Domain { get; set; }

Answer 5

Dies liegt daran, wenn Sie jemals das Feld zu einer Immobilie in der Zukunft ändern wollten Sie noch andere Baugruppen brechen würde, die davon abhängig sind.

Es ist gute Praxis, alle Felder privat zu halten und sie in ihren Eigenschaften wickeln, so dass Sie die Möglichkeit haben, die Validierung oder eine andere Logik in der Zukunft hinzuzufügen, ohne dass alle Verbraucher neu zu kompilieren (oder in diesem Fall Erben) Ihre Klasse.

Answer 6

In Antwort auf Ihre Frage ... ja.

Allerdings würde ich nur die Auto-Eigenschaft Syntax:

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

Answer 7

Grundsätzlich Eigenschaften bieten mehr als Rückkehr oder ein Mitglied zu setzen. Sie ermöglichen es, Logik hinzufügen, die eine richtige Eingabeformat, Bereich Validierung überprüfen konnte, etc.

Die gewählte Antwort von der Verbindung ist es am besten ausdrückt, „bieten Eigenschaften Verkapselung. Sie benötigt encapulate können jede Validierung / Formatierung / Umwandlung in den Code für die Eigenschaft. Diese für die Felder zu tun wäre schwierig.“

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

Answer 8

Zusätzlich zu den anderen Antworten hier erwähnt, öffentliche / geschützte Elemente, die mit einem Unterstrich beginnen, sind nicht CLS-kompatibel , dass es nicht erforderlich ist für .NET-Sprachen-Mitglieder mit führenden Unterstrichen zu unterstützen, so dass jemand aus Ihrer Klasse in einer anderen .NET-Sprache vererben kann zugreifen können, dass bestimmte nicht geschützt Mitglied.

ich weiß, ist es wahrscheinlich nicht auf Sie zutreffen, aber es könnte einen Teil des Grundes für die Code-Analyse-Warnung sein.