Felder vs Eigenschaften
Montag, 1. Februar 2010 09:37
Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen.
Bisher sind in dieser Reihe folgende Kommentare erschienen:
Heute, am 1. Februar 2010, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:
Felder vs Eigenschaften
So wohl Golo wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Golos Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:
An mehreren Orten wird debattiert, ob es nun besser sei eine öffentliche Eigenschaft, oder öffentliches Feld zu benutzen.
Teilweise gehen die Meinungen Richtung KISS oder YAGNI, was auch teilweise nachvollziehbar war, als es noch keine automatischen Eigenschaften gab.
Eine Eigenschaft ist jedoch nicht dasselbe wie ein Feld, es hat eine andere Bedeutung.
Während ein Feld nur ein einfacher Datencontainer darstellt, also eine Variable auf Instanzebene, repräsentiert eine Eigenschaft eine Schnittstelle zu Daten jeglicher Art.
Eine Eigenschaft kann bspw. auch Daten aus mehreren Feldern und noch einer zusätzlichen Berechnung haben.
Die Implementierung einer Eigenschaft kann ohne Bedenken geändert werden, ohne das ein Benutzer neu kompilieren muss, es besteht also eine binäre Kompatibilität.
Das ist ein nicht zu unterschätzender Vorteil gegenüber Eigenschaften, der es durchaus Wert ist, mehr Schreibarbeit und Code auf sich zu nehmen.
In den Framework Design Guidelines von Microsoft steht unter anderem auch:
Do not use instance fields that are public
Zu all diesen Vorteilen kommt noch hinzu, das beim Databinding explizit öffentliche Eignschaften gefordert sind.
Der aus meiner Sicht einzige Vorteil von öffentlichen Feldern ist Geschwindigkeit, sie sind definitiv schneller.
Allerdings sollte sowas - nur wenn nötig (Siehe auch Speedfreak) - auch nur in einer internen API so genutzt werden, die unter eigener Kontrolle steht.
Werden alle Vorteile der Eigenschaften zusammengezogen und ist keine Optimierung nötig, sollte immer eine Eigenschaft anstelle eines öffentlichen Feldes genutzt werden.
PS: Das Buch Framework Design Guidelines ist sehr zu empfehlen!
Tags:
C#, Streitgespräch, Felder, Eigenschaften, vs
ASP / ASP.NET MVP 2010
Dienstag, 19. Januar 2010 20:23
Anfang Jahr erhielt ich eine Email von Microsoft, das ich für das Jahr 2010 renominiert wurde :)
Das freut mich ungemein und ich möchte mich bei den Betreibern und Moderatoren von ASP.NET Zone und myCSharp bedanken.
Diese Auszeichnung durfte ich jetzt schon das vierte Mal in Folge entgegennehmen, wobei 4 meine Lieblingszahl ist :)
Sicherlich finde ich die Zeit auch mal in Konstanz beim .NET Stammtisch Konstanz / Kreuzlingen vorbeizuschauen und einen Vortrag zu halten.
Auf ein erfolgreiches Jahr 2010!
Tags:
ASP.NET, MVP, Microsoft, Neuigkeiten
this oder kein this
Freitag, 1. Januar 2010 09:37
Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen.
Bisher sind in dieser Reihe folgende Kommentare erschienen:
Heute, am 1. Januar 2010, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:
this oder kein this
So wohl Golo wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Golos Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema.
Generell ist es sinnvoll, wenn ohne weiteres Zutun gleich erfasst werden kann, ob es sich um eine lokale, statische oder instanzbehaftete Variable handelt.
Aus diesem Grund gibt es Konventionen, wie etwas auszusehen hat, sei dies mit Pascal- (fooBar) / Camel-Casing (FooBar) oder durch Prä- / Postfixe (m_foo, foo_m).
Im Allgemeinen hat es sich bei mir so entwickelt, dass ich mich immer mehr zu der empfohlenen Microsoft Konvention hin bewegt habe, was die Einarbeitung in andere Projeke um einiges leichter macht,
da diese Konvention häufig – wenn auch teilweise abgeändert – verwendet wird.
Im aktuellen Streitgespräch geht es darum, ob this verwendet wird / nicht verwendet wird und wo es verwendet wird.
this wird zwanghaft benötigt, um auf die Referenz auf sich selber, in die Hand zu bekommen.
Beispielsweise wenn in einer User-Klasse eine .Save-Methode angeboten wird, die ihrerseits aber einen Service benutzt um sich speichern zu lassen:
public class User
{
public void Save()
{
ServiceLocator
.Resolve<IUserService>()
.Save(this);
}
}
Erweiterungsmethoden benutzen this als Kennzeichnung:
static void ForEach<T>(this IEnumerable<T> source, Action<T> action)
{
foreach (var item in source)
{
action(item);
}
}
Bei einer Indexerdeklaration wird this auch benötigt:
public User this[sring index]
{
get { return this._list[index]; }
set { this._list[index] = value; }
}
Ein andere Stelle wo this benutzt werden muss, ist beim angeben von zusätzlichen Konstruktoren von sich selbst, die auch noch aufgerufen werden sollen:
public class UserService
{
private readonly IRepository<User> _userRepository;
public UserService() : this(new XmlUserRepository())
{
}
public UserService(IRepository<User> userRepository)
{
_userRepository = userRepository;
}
}
Im ersten Konstruktor wird angegeben, das auch der zweite Konstruktor mit einem Parameter aufgerufen werden soll.
Wenn die Instanzvariable “_userRepository” keinen Unterstrich hätte – also “userRepository” – müsste this verwendet werden, damit der Kompiler zwischen Instanzvariable und Argument unterscheiden kann, also:
private readonly IRepository<User> userRepository;
public UserService(IRepository<User> userRepository)
{
this.userRepository = userRepository;
}
Zu Anfang habe ich das Präfix “_” vor einer Instanzvariable benutzt, so kann man – auch im Intellisense – ohne Probleme auswählen und unterscheiden, da alle schön gruppiert sind.
In Visual Studio 2005 gab es allerdings kein Intellisense bei der Eingabe von “_test” im Code-Editor.
Ich habe dort “this._test” genutzt, denn es ist ja ein Instanzmember und mit der Eingabe von “this.” gab es dann Intellisense.
Ab Visual Studio 2008 gibt es bereits bei der Eingabe von “_” Intellisense, somit wäre “this” überflüssig. Allerdings habe ich mir angewöhnt, this überall anzugeben, wo sich etwas auf die Instanz bezieht.
Also für Methodenaufrufe auf der Instanz (in der Regel protected oder private Methoden), Eigenschaften sowie Instanzfelder.
Es ist so möglich auf den ersten Blick zu unterscheiden und erfassen, was eine lokale Variable ist, was ein statisches Feld / Konstante. Oder doch eine Instanzvariable?.
Was meint ihr dazu?
Tags:
C#, Streitgespräch, this
InternalsVisibleToAttribute und signierte Assemblies: So funktionierts garantiert.
Freitag, 4. Dezember 2009 16:46
Stellt euch vor, ihr habt zwei Assemblies:
- MyProject.Core
- MyProject.Core.Tests
Im Core-Projekt gibt es Typen, die nicht öffentlich gemacht werden sollten, allerdings für die UnitTests zugänglich sein sollen.
Nun, das ist ein kleines Problem, wenn man das Attribut “InternalsVisibleTo” kennt, mithilfe folgender Dekleration in der AssemblyInfo.cs des MyProject.Core-Projekts kann dies einfach erledigt werden:
[assembly: InternalsVisibleTo("MyProject.Core.Tests”)]
Das macht sogar sehr viel Sinn, denn sonst können Kollisionen und Verwechslungen der Extensionmethods beim Endbenutzer vorkommen.
Soweit, so gut. Die Typen der MyProject.Core-Assembly sind jetzt in der MyProject.Core.Tests-Assembly sichtbar.
Müssen die Projekte jedoch signiert sein, kommt es zu einem grösseren Problem.
In mehreren Blogs sind die nötigen Schritte beschrieben, jedoch werden da wichtige Punkte nicht genannt, die einem zur Verzweiflung treiben können.
Die sind wie folgt:
- Alle involvierten Assemblies müssen signiert werden.
- Der PublicKey muss vom Projekt bezogen werden, bei dem die Internals sichtbar werden sollen, in unserem Fall also das MyProject.Core.Tests-Projekt.
Nach einer weiteren Suche bin ich schlussendlich auf einem (selbsternannten) Newbie-Blog fündig geworden.
Noch später sties ich dann auf die folgende Anleitung, die eigentlich alles beinhaltet, sodass ich nicht alles im Detail niederschreiben muss, trotzdem die wichtigen Punkte nennen kann und vorallem die Lösung wieder einmal finde:
Also, beachtet die oben stehenden zwei Punkte und haltet euch an folgende Anleitung:
Tags:
Tipps, .NET, Assembly, InternalsVisibleTo, StrongName