Public oder SerializeField für Inspector-Sichtbarkeit?

Verschiedene Möglichkeiten, um Felder im Inspektor anzuzeigen

Die Felder einer MonoBehaviour-Klasse lassen sich im Inspector des Unity-Editors direkt bearbeiten sofern sie als public deklariert und von einem durch den Inspector unterstützten Typ sind.

Public-Elemente sind Inspector befüllbar.

Public-Elemente sind Inspector befüllbar.

Der Hack mit [SerializeField]

Felder, die mit private oder auch protected geschützt sind, erscheinen im Inspektor nicht. Unity bietet allerdings ein Attribut namens SerializeField an, das die Sichtbarkeit im Inspektor auch für private Elemente erzwingt.

Ein Seiteneffekt der SerializeField-Annotation ist, dass auch geschützte Felder im Inspector erscheinen.

Ein Seiteneffekt der SerializeField-Annotation ist, dass auch geschützte Felder im Inspector erscheinen.

In der Unity-Dokumentation der SerializeField-Anmerkung heißt es gleich zu Beginn, „you will almost never need this“, also „dies wirst Du so gut wie nie brauchen“. Ein solcher Hinweis sollte schon die Vermutung nahelegen, dass die Verwendung des SerializeField-Attributs nicht der korrekte Weg ist, um Felder im Inspector sichtbar zu machen. Der Begriff selbst sagt außerdem schon aus, dass er für etwas anderes entworfen wurde: „Serialize Field“ heißt soviel wie „speichere das Feld“. Das bezeichnet technisch also etwas anderes als die Anzeige im Inspektor, denn sonst würde es nicht SerializeField, sondern ShowInInspector heißen.

Die Bedeutung von Sichtbarkeitsmodifikatoren

Sehen wir uns den semantischen, also bedeutungsbezogenen, Unterschied etwas näher an.

Public räumt anderen Klassen Zugriffsrechte ein.

Public räumt anderen Klassen Zugriffsrechte ein.

Eine Klasse kann verschiedene Elemente beinhalten und die Klasse selbst hat immer Zugriff darauf. Kommt nun eine zweite Klasse dazu, so wird durch Sichtbarkeitsmodifikatoren geregelt, worauf diese Klasse zugreifen darf. Der Modifikator public macht das Element nach außen sichtbar, so dass die andere Klasse darauf zugreifen darf. Private dagegen schützt das Element, so dass die äußere Klasse keinen Zugriff hat.

Was SerializeField wirklich macht

Die andere Klasse kann z.B. auch der Serialisierer bzw. Deserialisierer sein, der einen Mechanismus implementiert, um die Werte, die Elementen zugewiesen wurden in eine Datei zu speichern bzw. aus dieser wiederum zu laden. Aufgrund der C#-Sichtbarkeitskonzepte werden hier nur public-Elemente einbezogen. Um eine Klasseninstanz, also ein Objekt, vollständig zu speichern, kann es aber nötig sein, auch private Elemente mitzuspeichern. Um dies schnell und einfach möglich zu machen, stellt Unity das Attribut SerializeField zur Verfügung, das den Serialisierer anweist, die so markierten Elemente ebenfalls mitzuspeichern – unabhängig von deren Sichtbarkeitsregel.

SerializeField umgeht die Sichtbarkeitseigenschaften.

SerializeField umgeht die Sichtbarkeitseigenschaften.

Der entscheidende Unterschied

Der Inspector im Unity-Editor ist letztlich nichts anderes als eine grafische Benutzeroberfläche, für diesen Serialisierungsvorgang, d.h. die gespeicherten Daten werden nicht mehr nur direkt über die Datei, sondern auch über ein Eingabeformular gelesen und geschrieben.

Wenn man nun den Inspector als außenstehende Klasse ansieht, was technisch auch der Fall ist, dann umgeht SerializeField die Sichtbarkeitseinstellung und gibt externen Komponenten Zugriff auf die internen Elemente einer Klasse, auf die es konzeptuell eigentlich keinen Zugriff haben sollte. Von der Code-Architektur her macht es so gesehen nicht viel Sinn SerializeField zu nutzen, denn entweder dürfen aussenstehende Klassen auf die Felder zugreifen – dann können sie auch public sein – oder sie dürfen eben keinen Zugriff haben, dann sollte das auch konsequent im Code so umgesetzt und private oder protected verwendet werden.

 

Werbung

 

 

 

 

Dr. René Bühling

Hi, mein Name ist René und ich möchte Dir dabei helfen, deinen Traum vom eigenen Computerspiel Wirklichkeit werden zu lassen. Mein erstes kommerziell veröffentlichtes Spiel habe ich Mitte der 1990er Jahre als Hobby-Projekt mit einem Basic-Dialekt unter Windows entwickelt. Seither verfolge ich das Thema Spieleentwicklung in Hobby, Studium und Beruf. Ich habe über 20 Jahre Erfahrung in allen Phasen des Entwicklungsprozesses, die ich gerne mit dir teilen möchte.