Feldentwurf
Aktualisiert: November 2007
Felder enthalten Daten, die einem Objekt zugeordnet sind. In den weitaus meisten Szenarien sollten nicht statische Felder in einer Bibliothek nicht für Entwickler sichtbar sein. Anhand der folgenden Richtlinien können Sie Felder auf ordnungsgemäße Weise beim Bibliotheksentwurf verwenden.
Stellen Sie keine Instanzfelder bereit, die öffentlich oder geschützt sind.
Öffentliche und geschützte Felder sind schlecht für die Versionserstellung geeignet und nicht durch Anforderungen an die Codezugriffssicherheit geschützt. Verwenden Sie statt öffentlich sichtbarer Felder private Felder, und machen Sie sie über Eigenschaften verfügbar.
Verwenden Sie konstante Felder für Konstanten, die sich niemals ändern.
Beispielsweise definiert die Math-Klasse E und PI als statische Konstanten.
Der Compiler fügt die Werte von const-Feldern direkt in den aufrufenden Code ein. Daher können const-Werte niemals geändert werden, ohne dass die Gefahr eines Kompatibilitätsproblems besteht.
Verwenden Sie für vordefinierte Objektinstanzen öffentliche, statische, schreibgeschützte Felder.
Beispielsweise stellt die DateTime-Klasse statische schreibgeschützte Felder bereit, mit denen Sie DateTime-Objekte abrufen können, die auf den maximalen oder minimalen Zeitwert festgelegt sind. Siehe MaxValue und MinValue.
Weisen Sie schreibgeschützten Feldern keine Instanzen änderbarer Typen zu.
Die mit einem änderbaren Typ erstellten Objekte können nach ihrer Erstellung geändert werden. Beispielsweise sind Arrays und die meisten Auflistungen änderbare Typen, während Int32, Uri und String unveränderliche Typen sind. Bei Feldern, die einen änderbaren Verweistyp enthalten, verhindert der read-only-Modifizierer das Überschreiben des Feldwerts, schützt jedoch den änderbaren Typ nicht vor Änderungen.
Im folgenden Codebeispiel wird das Problem der Verwendung schreibgeschützter Felder veranschaulicht. Die BadDesign-Klasse erstellt ein schreibgeschütztes Feld und macht es mit einer schreibgeschützten Eigenschaft verfügbar. Dies verhindert nicht, dass die ShowBadDesign-Klasse den Inhalt des schreibgeschützten Felds ändert.
Imports System
Namespace Examples.DesignGuidelines.Fields
Public Class BadDesign
Public Readonly dataValues as Integer() = {1,2,3}
Public ReadOnly Property Data as Integer ()
Get
Return dataValues
End Get
End Property
Public Sub WriteData()
For Each i as Integer In dataValues
Console.Write ("{0} ", i)
Next i
Console.WriteLine()
End Sub
End Class
Public Class ShowBadDesign
Public Shared Sub Main()
Dim bad as BadDesign = new BadDesign()
' The following line will write: 1 2 3
bad.WriteData()
Dim badData as Integer() = bad.Data
For i as Integer = 0 To badData.Length -1
badData(i) = 0
Next i
' The following line will write: 0 0 0
' because bad's data has been modified.
bad.WriteData()
End Sub
End Class
End Namespace
using System;
namespace Examples.DesignGuidelines.Fields
{
public class BadDesign
{
public readonly int[] data = {1,2,3};
public int [] Data
{
get {return data;}
}
public void WriteData()
{
foreach (int i in data)
{
Console.Write ("{0} ", i);
}
Console.WriteLine();
}
}
public class ShowBadDesign
{
public static void Main()
{
BadDesign bad = new BadDesign();
// The following line will write: 1 2 3
bad.WriteData();
int[] badData = bad.Data;
for (int i = 0; i< badData.Length; i++)
{
badData[i] = 0;
}
// The following line will write: 0 0 0
// because bad's data has been modified.
bad.WriteData();
}
}
}
Copyright für einzelne Teile 2005 Microsoft Corporation. Alle Rechte vorbehalten.
Copyright für einzelne Teile Addison-Wesley Corporation. Alle Rechte vorbehalten.
Weitere Informationen zu Entwurfsrichtlinien finden Sie im Buch "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" von Krzysztof Cwalina und Brad Abrams, veröffentlicht von Addison-Wesley, 2005.