26 Dependency Properties
In den vorhergehenden Abschnitten haben Sie einen Überblick darüber erhalten, wie die Struktur und der Aufbau einer WPF-Anwendung aussehen. Sie haben erfahren, dass die Benutzeroberfläche mit XAML beschrieben wird, und die Syntax von XAML gelernt. Einige WPF-spezifische Techniken habe ich Ihnen auch gezeigt, beispielsweise die Styles und die Datenbindungen.
Widmen wir uns nun einem Thema, das im Verlauf des WPF-Teils dieses Buches immer wieder erwähnt wurde, aber noch nicht tiefergehend behandelt worden ist: die Abhängigkeitseigenschaften, im Englischen auch Dependency Properties. Wie Sie wissen, sind Dependency Properties im Zusammenhang mit Datenbindungen, Styles und auch Animationen zwingend notwendig. Viele mit der WPF eingeführte Programmiertechniken setzen also Abhängigkeitseigenschaften voraus.
Im engen Zusammenhang mit den Abhängigkeitseigenschaften stehen auch die angehängten Eigenschaften (Attached Properties). Dabei handelt es sich um Eigenschaften, die nicht in der Klasse eines Elements definiert sind, sondern von einer hierarchisch übergeordneten Komponente bereitgestellt werden. Die Eigenschaften Grid.Row und Grid.Column sind typische angehängte Eigenschaften, die uns immer dazu dienten, ein Element in einer bestimmten Zelle eines Grid zu positionieren. Angehängte Eigenschaften werden uns zum Schluss dieses Kapitels beschäftigen.
26.1 Die Charakteristik von Abhängigkeitseigenschaften
Mit CLR-Eigenschaften haben wir schon viel gearbeitet. Sie sind uns vertraut geworden. Wir wissen, dass eine CLR-Eigenschaft ein private oder protected deklariertes Feld ist, wobei der Zugriff auf den Wert des Feldes über die in einer Eigenschaftsmethode definierten get- und set-Zweige erfolgt. Ferner wissen wir, dass jedes Objekt eines bestimmten Typs die gleichen Eigenschaften aufweist, die für jedes einzelne Objekt separat gespeichert werden.
Bei einer genauen Analyse muss man feststellen, dass diese Art der Objektbeschreibung unnötig viele Speicherressourcen in Anspruch nimmt. Warum das? Betrachten wir zur Verdeutlichung exemplarisch eine Schaltfläche (Typ Button) aus der WinForm-API. Mit ca. 50 verschiedenen Eigenschaften wird eine Schaltfläche beschrieben. Enthält ein WinForm drei davon, werden ungefähr 150 Daten für die drei Objekte im Speicher vorgehalten. Stellen wir uns nun die Frage, wie viele Eigenschaften tatsächlich für jedes der drei Button-Objekte individuell eingestellt sind: die Positionswerte, die Beschriftung, wahrscheinlich auch die Größe. Die meisten Eigenschaften behalten jedoch ihren ursprünglichen Standardwert bei. Wäre es nicht ressourcenschonender, alle unveränderten Standardwerte in einem zentralen Speicher allen Schaltflächen gemeinsam zur Verfügung zu stellen? Die WinForm-API kann diese Überlegung nicht umsetzen, die WPF mit den Abhängigkeitseigenschaften hingegen schon.
Die Abhängigkeitseigenschaften der WPF gehen mit den zur Verfügung stehenden Ressourcen also ausgesprochen ökonomisch um. Solange die Eigenschaft eines Objekts nicht individuell eingestellt wird, wird dafür auch kein Speicherplatz in Anspruch genommen und der Wert einem allgemeinen »Reservoir« entnommen. Erst wenn die Eigenschaft eines Objekts individuell eingestellt wird, stellt das System dafür lokale Ressourcen zur Verfügung.
Wir brauchen uns keine großen Gedanken über die Verwaltung der Abhängigkeitseigenschaften zu machen. Das WPF-Subsystem erledigt alle damit im Zusammenhang stehenden Aufgaben für uns. Wir müssen lediglich die Eigenschaft als Dependency Property dem System bekannt geben, besser ausgedrückt, wir müssen sie registrieren. Wie das gemacht wird und was dabei zu berücksichtigen ist, erfahren Sie in diesem Kapitel.
Die WPF unterstützt nicht nur Abhängigkeitseigenschaften, sondern darüber hinaus auch die herkömmlichen CLR-Eigenschaften. Diese sind jedoch eindeutig in der Minderheit. Einer Eigenschaft kann man auf den ersten Blick nicht ansehen, ob sie als CLR- oder Abhängigkeitseigenschaft implementiert ist. Im Zweifelsfall müssen Sie das in der Dokumentation nachlesen.
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.
