OOP Nutzen von Accesors?

[djafix]

hallo,
ich hab mal eine eher allgemeine frage, die auch für andere programmiersprachen als java gilt..und zwar:

ist es eigentlich guter programmierstil accesors zu nutzen? da diese ja public sind, kann ich mir nicht ganz vorstellen, dass das so das gelbe vom ei ist? kann mir das vielleicht einer erklären :idea:

 

[Joose]

hallo,
ich hab mal eine eher allgemeine frage, die auch für andere programmiersprachen als java gilt..und zwar:

Somit ein Thema welches eher in die Plauderecke gehört, aber nicht zu den Java Anfänger Themen

....... accesors .....

Leider konnte mir nicht mal Google verraten was das sein soll mir werden werden dann immer Damen-Accessoires vorgeschlagen

 

[djafix]

also vereinfacht erklärt sind accesors folgendes:

private String name;
public String Name;
{
      get{
            return name;
      }
      set{
           name = value;
      }

in java gibt es zwar dieses get/set-konstrukt soweit ich weiß nicht, aber in c# z.b. ist das gängige praxis...ich kann mir nur nicht erklären ob das nun eigentlich gut oder schlecht ist

man kann dann also quasi Name = "test" schreiben und somit würde name den wert "test" haben.

 

[Thallius]

Das Ganze nennt sich (eigentlich überall, ich kann mir kaum vorstellen das das in C# anders ist) Getter und Setter.
Und diese machen eigentlich immer Sinn, nur sollte die zugehörige Property dann auch private sein. Setter und Getter zu benutzen ist die feinste Art OOP zu programmieren, nur leider sind die meisten zu Faul dazu und machen die Porperty einfach public und greifen direkt darauf zu. Damit enhebe ich der Klasse die Kontrolle über die Porperty was schlicht weg schlechter OOP Stil ist.

Gruß

Claus

 

[Joose]

Ach so, verstehe.
In C# kann man Properties dazu sagen (welche get/set Methoden für Attribute ersetzen).

Ich muss sagen ich vermisse Properties in Java sehr, aber ich glaub mal gelesen zu haben diese Syntax zu Java hinzugefügt werden soll. (irgendwann einmal). Ich finde sie sehr angenehm.

 

[Aristro]

in java gibt es zwar dieses get/set-konstrukt soweit ich weiß nicht

private String name; 

public String getName(){
    return this.name;
}

public void setName(String value){
     this.name = value;
}

aber in c# z.b. ist das gängige praxis...ich kann mir nur nicht erklären ob das nun eigentlich gut oder schlecht ist

In Java wie auch in c# werden getter/setter verwendet um Objekte zu kapseln. Außerdem können mithilfe der setter/getter Objekte validiert werden.

Für OOP sind Akzessor wichtig und können in den meisten Entwicklungsumgebungen auch schnell generiert werden, sodass der zusätzliche Aufwand sehr gering ist. ( In eclipse z.B. mit dem Shortcut Strg +1 auf dem Feld anwenden dem du einen getter/setter hinzufügen möchtest)

mfg

Aristro opcorn:

 

[Joose]

In Java wie auch in c# werden getter/setter verwendet um Objekte zu kapseln. Außerdem können mithilfe der setter/getter Objekte validiert werden.

Jein in C# werden bevorzugt die Properties verwendet statt "klassischen" settern/gettern.
Der einzige Unterschied ist die Syntax

 

[Thallius]

Jein in C# werden bevorzugt die Properties verwendet statt "klassischen" settern/gettern.
Der einzige Unterschied ist die Syntax

Ja man spart sich zwei Klammern

Gruß

Claus

 

[Joose]

Je nach Schreibweise auch etwas mehr

private String name;

public String Name {
   get;
   set;
}

oder 

public String Name {
   get {
      return name;
   }
   set {
      name = value;
   }
}

Ich finde auch schöner zu lesen

this.Name = "Fritz";

statte

this.setName("Fritz");

 

[djafix]

naja was getter/setter sind ist mir schon klar mir gings lediglich darum ob das nicht irgendwie komisch ist über die getter/setter einer variable auf eine andere variable zuzugreifen.... aber da es das in java anscheinend so eh nicht gibt, dann kann das im prinzip auch schnuppe sein

 

[Joose]

mir gings lediglich darum ob das nicht irgendwie komisch ist über die getter/setter einer variable auf eine andere variable zuzugreifen....

Was genau meinst du damit?

 

[djafix]

naja wie ichs beschrieben habe...quasi die propertys(keine methoden),die öffentlich zugänglich sind und damit die privaten variablen getten/setten

 

[Joose]

...quasi die propertys(keine methoden),die öffentlich zugänglich sind und damit die privaten variablen getten/setten

Das passt ja eh, du willst Werte setzen können aber das was gesetzt wird auch überprüfen!
Somit muss den "Umweg" über getter/setter gehen. Wenn es egal wäre welchen Wert du draufschreibst könntest du dir die getter/setter auch Sparen.

 

[ceving]

Das passt ja eh, du willst Werte setzen können aber das was gesetzt wird auch überprüfen!

Das würde aber nur den Setter motivieren.

Die Motivation für den Getter kommt aus dem Wunsch, die Implementation der Klasse ändern zu können, ohne dass es einen Einfluss auf andere Klassen hat, die deine Klasse verwenden.

Beispiel: du schreibst eine Klasse ohne Accessor (mit 2 s), auch Mutator genannt. Wenn eine andere Klasse deine Klasse verwenden will, greift sie direkt auf die Member-Variablen zu. Jetzt will jemand deine Klasse aber in einem Server verwenden, der parallel über mehrere Threads verteilt Requests verarbeitet und dafür deine Klasse verwenden soll. Das bedeutet, du musst den Zugriff Thread-sicher machen. Und das bedeutet, dass man nicht mehr direkt auf die Member-Variablen zugreifen kann. Statt dessen muss der Zugriff über alle Threads synchronisiert werden. Das bedeutet, dass vor jedem Zugriff ein Lock akquiriert werden muss. Hättest du eine Klasse mit Getter programmiert, wäre es problemlos möglich, diesen Mechanismus in deinem Getter zu ergänzen ohne, dass es Einfluss auf den Code der anderen Klassen hätte. Wenn du eine Klasse ohne Getter schreibst, musst du sie spätestens jetzt auf Getter umstellen und alle anderen Klassen müssen geändert werden, weil dort an Stelle des Member-Variablen-Zugriffs jetzt der Getter-Aufruf stehen muss.

Und um sich diese Änderung im Falle eines Falles zu ersparen, verwendet man direkt von Anfang an gleich Getters, auch wenn man sie in den meisten Fällen eigentlich nicht braucht. Und zusätzlich spekuliert man darauf, dass der Compiler sie weg optimiert, wenn sie nicht wirklich ausprogrammiert sind, denn ein Methoden-Aufruf ist eigentlich langsamer als der Zugriff auf eine Member-Variable.