Propertys oder Felder?

[Helishcoffe]

Das ist eigentlich etwas wo ich mir schon länger immer wieder mal gedanken drüber mache. Benutzt ihr in Unity für öffentliche Variablen Eigenschaften oder Felder? 

Die, die von .NET kommen würden mir wahrscheinlich direkt sagen:

Zitat

Na ganz einfach: Propertys! Validierung von Variablen direkt bei der Zuweisung und beim Auslesen ist das A und O. Es gehört schließlich zu einem guten Programmierstil, Eigenschaften statt Felder zu verwenden für Öffentliche Variablen

In .NET benutze ich auch immer Eigenschaften weil sie einfach enorme Vorteile bieten und meiner Meinung auch zu einem guten Programmirstil gehört. 

Doch in Unity sieht man Eigenschaften in Scripts entweder gar nicht oder total gemischt. Da werden dann Validierungen dann in jedem Frame in der Update() ausgeführt oder einfach nur in Start(). Ich habe noch kein Script gesehen, welches nur Propertys verwendet für öffentliche Member. Schließlich kann man sie im Inspector genau so zuweisen wie Felder. 

Hat das bestimmte Gründe? Ich bin bis heute nämlich immernoch der Meinung, dass es von JavaScript kommt, welches in Unity ja früher häufiger zum Einsatz kam und es einfach eine Sache der Gewohnheit und des Gefühls ist. Oder hat das wirklich technische Gründe? 

[Zer0Cool]

Ich würde Property's verwenden, wenn ich sie brauche. Beispielsweise, wenn ein Wert nur gelesen werden darf -> Property. Wenn ich innerhalb der Property eine Validierung machen muss , beispielsweise Property Health und wenn Health hier nicht größer wie 100 werden darf -> Property. Ansonsten finde ich reichen normale Felder, man muss nicht alles verkomplizieren mit dem Grund "guter Programmierstil". Mich "nerven" Property's auch relativ oft, weil man hier keine direkte Zuweisung vornehmen kann bei einer untergeordneten Eigenschaft (siehe rotation Eigenschaft beim Transform).

[Helishcoffe]

Propertys lassen sich ja auch verkürzt schreiben mit 

//Als Feld:
public int Health = 100;

//Als Property:
public int Health { set; get; } = 100;

Meiner Meinung nach ist die 2. Variante schöner als die 1. (zumindest wenn man Propertys und Felder in einem Script mischt). Aber wenn es eh nur Geschmackssache ist und kaum technische Unterschiede bietet, dann kann das ja jeder für sich selber wissen. 

[Sascha]

Was @Zer0Cool sagt. Propertys zu nutzen, wo auch ein ganz normales Feld funktioniert, finde ich schon etwas käse.

Vorteile: Wenn man überhaupt keine Felder mehr benutzt, ist das schön konsistent. Dann kann man wunderbar mal einen Setter oder Getter modifizieren, ohne dafür von Feld auf Property umzusetellen.

Nachteile: Wie erwähnt haben Propertys eben auch Nachteile wie den, dass man keine Werte innerhalb des Structs verändern kann, das in einer Property steht. Wenn ich mich nicht irre, ist der Aufruf eines Setters oder Getters sogar jedes Mal ein kompletter Methodenaufruf auf dem Stack.

vor einer Stunde schrieb Helishcoffe:

Da werden dann Validierungen dann in jedem Frame in der Update() ausgeführt oder einfach nur in Start().

Ja, gibt halt auch viel Crap Code für Unity.

vor einer Stunde schrieb Helishcoffe:

Ich habe noch kein Script gesehen, welches nur Propertys verwendet für öffentliche Member.

Die allermeisten existierenden Unity-Scripts sind ja auch für C# 4, da kann man ja nicht einmal bei der Deklaration einen Wert initialisieren.

vor einer Stunde schrieb Helishcoffe:

Schließlich kann man sie im Inspector genau so zuweisen wie Felder.

Huch? Seit wann das denn bitte?

[Zer0Cool]

Zitat

Was @Zer0Cool sagt. Propertys zu nutzen, wo auch ein ganz normales Feld funktioniert, finde ich schon etwas käse.

Hab ich doch gar nicht gesagt, ich meinte es genau andersherum. Ich bevorzuge Felder wenn ich die Möglichkeiten von Properties nicht brauche ...

Unterschiede gibt es schon probier mal:

//Als Feld:
public Vector3 direction1;

//Als Property:
public Vector3 direction2 { set; get; }

und jetzt versuche mal folgendes:

direction1.x = 50f;
direction2.x = 50f;

Daher bevorzuge ich Variante 1, wenn ich keine Validierung benötige oder nicht Lesen oder Schreiben verbieten möchte.

[Sascha]

vor 29 Minuten schrieb Zer0Cool:

Ich bevorzuge Felder wenn ich die Möglichkeiten von Properties nicht brauche

Ich hab das jetzt ein paar Mal gelesen und es ist für mich exakt dieselbe Aussage

"Wenn Feld geht, Feld, sonst Property."

[Zer0Cool]

Ah ich hatte deinen 1. Satz auch falsch verstanden, aber nun geht mir ein Licht auf  

[Life Is Good]

vor 9 Stunden schrieb Helishcoffe:

Hat das bestimmte Gründe? Ich bin bis heute nämlich immernoch der Meinung, dass es von JavaScript kommt, welches in Unity ja früher häufiger zum Einsatz kam und es einfach eine Sache der Gewohnheit und des Gefühls ist. Oder hat das wirklich technische Gründe? 

Ich würde mal behaupten, dass da eher die .Net Community der Gewohnheit folgt.
Hieraus

public int Health {get; set;} = 100;

macht der Compiler einfach

private int health = 100;

public int GetHealth ()
{
	return health;
}

public int SetHealth (int value)
{
	health = value;
}

In anderen (OOP) Sprachen (z.B. Java) ist es üblich eine Get und / oder Set Methode anzulegen, einfach weil's da nun mal keine properties für gibt ¯\_(ツ)_/¯
Wenn du da also nichts weiter mit get / set speziell anstellst (wie Sascha und Zer0 schon meinten), ist das eher Dogma als guter Stil.

Für den Unity Editor speziell gibt's übrigens das [SerializeField] Attribut, damit auch private Felder serialisiert werden.
 

 

[runner78]

Ich halte mich im grunde nach der Regel:

Felder immer private/protected
Properties um Felder bei bedarf nach außen zugänglich zu machen.

Structs in Unity sind bei mir die einzige Ausnahme wo ich auch bei bedarf öffentlich Felder verwende.