2011-01-07 12 views
8

Wenn Sie eine Klasse in C# schreiben, ist es eine gute Idee, alle privaten Membervariablen als private readonly zu markieren, wenn sie nur im Konstruktor zugewiesen sind und nicht an anderer Stelle geändert werden können Klasse? Oder ist das Overkill?C# -Klasse und readonly-Member

+0

Danke für alle Kommentare. Ich werde weitermachen und meine Mitglieder nur als gelesen markieren. Prost. – Bobbo

Antwort

10

Ja, persönlich glaube ich, dass es eine gute Idee ist. Ich versuche, Typen möglichst unveränderlich zu halten, und eine Variable readonly ist eine gute Start zu diesem zu erklären. Es ist natürlich nicht das All-und-End, wenn diese Variable etwas veränderlich ist (z.B. ein StringBuilder oder ein Array), dann hilft es wirklich nicht viel. Ich würde trotzdem die Variable schreibgeschützt machen, um klar zu machen, dass ich den Wert der Variablen selbst nicht ändern möchte - und mich daran zu hindern, dies zufällig irgendwo in derselben Klasse zu tun, möglicherweise Monate oder Jahre später.

+0

Sie sind ein Guru in Java und C#. Dies ist im Wesentlichen das C# -Aquivalent dieser Java-Frage. http://stackoverflow.com/questions/137868/using-final-modifier-whene-applicable-in-java Ich frage mich, warum die Diskussion hier scheint so viel zahmer als die Java. – RAY

+0

@RAY: Nein, bedenke, dass 'final' in Java auf mehr als nur Variablen zutrifft - es ist eine Kombination von' readonly' und 'sealed' in C# ... und wenn du Leute fragst, ob Klassen versiegelt werden sollen oder nicht, du wirst eine hitzigere Debatte sehen ... –

+0

Wahr. Die verknüpfte Frage fragt spezifisch nach lokalen und Klassenvariablen (Argumente und Felder) obwohl ... – RAY

4

Ja, das ist genau das, was readonly angibt. Wenn Sie bereits wissen (oder zumindest davon ausgehen können), dass Sie es nirgendwo anders zuweisen werden, dann ist es eine gute Idee, es zu markieren readonly. Immerhin ist es einfacher, readonly zu entfernen, als es später hinzuzufügen.

0

Ja - Sie werden nicht auf Probleme mit ihren Werten stoßen, die später von Code geändert werden, der von anderen Entwicklern geschrieben wurde, die nicht wussten, dass sie schreibgeschützt sein sollten.

1

Wow, was für eine gute Frage und eine, die rein mit Meinungen beantwortet wird. Meiner Meinung nach erzeuge ich immer nur Eigenschaften für die Variable. Ein Beispiel ist wie folgt.

private int _myInt; 
private int myInt {get{return _myInt;}} 
+4

Das erlaubt immer noch, dass die Variable in der Klasse mutiert wird - sie zeigt nicht die Absicht des Entwicklers * nicht * an, sie innerhalb einiger anderen zu mutieren Methode. –

-1

Wenn ich nur einmal eine Variable initialisiere und niemals schreibe, würde ich sie const machen.

http://en.csharp-online.net/const,_static_and_readonly

+1

Sie können es nicht const machen, wenn der Wert keine Kompilierzeitkonstante ist oder wenn es ein Instanzfeld ist. –

+0

Richtig, ich halte const effizienter, weil es kompiliert * ist.Wenn das Element nicht const sein kann, wird eine andere Route benötigt, wie z. B. readonly. Sonst würde ich es const machen. –

+4

Auch wenn es vom richtigen Typ ist, könnte es immer noch eine schlechte Idee sein, es zu einem Const zu machen. Angenommen, Sie haben ein int-Feld "Versionsnummer". Machen Sie das nicht zu einem const, machen Sie es nur lesbar. Eine Versionsnummer ist eine Größe, die sich logisch * über die Zeit * ändert und daher nicht * konstant * ist. Verwende nur const für Dinge, die sich niemals verändert haben und ändert sich niemals *, wie der Wert von pi oder die Ordnungszahl von Blei. –

0

Read-only in Situationen sehr viel Sinn macht, wo Sie einen Dienstverweis durch Konstruktor übergeben, dh

public class MyViewModel { private readonly MyContext context; public MyViewModel(MyContext context) { this.context = context; } }

Sie natürlich Ihre Zusammenhang mit einem anderen überschrieben wollen nicht, weil Sie kann eine Menge Sachen abhängig von diesem bestimmten Dienst innerhalb der Klasse haben. Wenn es sich um einen Konstruktorparameter handelt, bedeutet das normalerweise, dass Sie sich auf diesen bestimmten Dienst oder dieses Objekt VERLASSEN, um den gültigen Zustand des Objekts zu erstellen und beizubehalten. Daher ist readonly ein guter Indikator dafür. Wenn private set auf property bedeutet, dass Sie es nicht außerhalb der Klasse ändern können, ist readonly eine zusätzliche Einschränkung, die die Dinge ein wenig sicherer und verständlicher macht.