Getter/Setter Methoden vs. properties

[Christian S.]

Hi,

überall wird propagiert, dass man das interne Verhalten einer Klasse (z.B. in Java oder C#) nach außen verstecken sollte. Das bedeutet v.a. dass man keine Objekt Variablen benutzen, sondern alles über getter/setter Methoden bzw. Properties ansprechen soll.

Wie ist es in JavaScript? Es ist zwar nicht so streng objektorientiert, aber dennoch möchte man ja sauberen Code schreiben.
Sollte ich also auch dort meine Objekt Variablen in setter/getter Methoden kapseln? Eine private ObjektVariable würde ich mangels des private Schlüsselworts z.B. mit einem "_" Präfix kennzeichnen, was sowieso schon oft Konvention ist.

get/set und __definegetter__ gibts ja leider nur im Firefox. Und ein onpropertychanged event für den IE und für jede Property als setter Ersatz zu machen, ist ja auch nicht das Gelbe vom Ei.

Gruß!

[Marc Reichelt]

Hallo Christian,

überall wird propagiert, dass man das interne Verhalten einer Klasse (z.B. in Java oder C#) nach außen verstecken sollte. Das bedeutet v.a. dass man keine Objekt Variablen benutzen, sondern alles über getter/setter Methoden bzw. Properties ansprechen soll.

Wie ist es in JavaScript? Es ist zwar nicht so streng objektorientiert, aber dennoch möchte man ja sauberen Code schreiben.
Sollte ich also auch dort meine Objekt Variablen in setter/getter Methoden kapseln? Eine private ObjektVariable würde ich mangels des private Schlüsselworts z.B. mit einem "_" Präfix kennzeichnen, was sowieso schon oft Konvention ist.

Wie in vielen Dingen gilt auch bei JavaScript: Entscheidend ist, was du draus machst.

Ich demonstriere den Sinn von get/set-Methoden gerne am Beispiel eines Raumschiffs.
In JavaScript könnte dies beispielsweise so aussehen:

function Spaceship() {  
  this._speed = 0;  
  
  this.getSpeed = function() {  
    return this._speed;  
  }  
  
  this.setSpeed = function(speed) {  
    this._speed = speed;  
  }  
}

Soweit könnte man statt den get/set-Methoden auch einfach das Attribut _speed verwenden, das ist klar.
Möchte man das Raumschiff aber nun im Verlauf der Entwicklung ändern, sodass es nur noch gültige Geschwindigkeiten (Zahlen im Bereich der Lichtgeschwindigkeit) entgegennimmt, ist dies nur mit einer set-Methode möglich.

Das folgende Beispiel illustriert dies:

function Spaceship() {  
  this.LIGHTSPEED = 299792458;  
  this._speed = 0;  
  
  this.getSpeed = function() {  
    return this._speed;  
  }  
  
  this.setSpeed = function(speed) {  
    if (Math.abs(speed) <= this.LIGHTSPEED) {  
      this._speed = speed;  
    }  
  }  
}

Ohne die get/set-Methoden müssten wir nun alle Codestellen anpassen, die das Attribut direkt ändern.

Auch in JavaScript gilt: Der Status eines Objekts wird konsistent gehalten.
Natürlich könnte bösartiger Code einfach das Attribut _speed ändern. Solange aber alle die Regel der Konsistenz einhalten ist die Fehlerbehebung viel einfacher, da er sich auf die Klasse beschränkt.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Struppi]

Ich demonstriere den Sinn von get/set-Methoden gerne am Beispiel eines Raumschiffs.
In JavaScript könnte dies beispielsweise so aussehen:

function Spaceship() {

this._speed = 0;

this.getSpeed = function() {
    return this._speed;
  }

this.setSpeed = function(speed) {
    this._speed = speed;
  }
}

  
In Javascript ist es sehr wohl möglich private Variabeln zu deklarieren, ich zeig das mal anhand des Beispiels (deshalb auch hier meine Antwort).  
~~~javascript
function Spaceship() {  
   var speed = 0;  
  
   this.getSpeed = function() {  
     return speed;  
   };  
  
   this.setSpeed = function(new_speed) {  
     speed = new_speed;  
   };  
}

Struppi.

[Christian S.]

Hi,

In Javascript ist es sehr wohl möglich private Variabeln zu deklarieren, ich zeig das mal anhand des Beispiels (deshalb auch hier meine Antwort).

function Spaceship() {

var speed = 0;

this.getSpeed = function() {
     return speed;
   };

this.setSpeed = function(new_speed) {
     speed = new_speed;
   };
}

>   
> Struppi.  
  
ja, ich weiß das. Aber ich finde es sehr unschön, die gesamte Klasse im Konstruktor dynamisch zu erstellen. Ich mach das lieber alles im prototype. Hat ja auch Vorteile. so wird z.B. für jedes Objekt eine neue Funktionsreferenz erstellt, sondern der prototype bemüht.  
  
Gruß!

[Struppi]

ja, ich weiß das. Aber ich finde es sehr unschön, die gesamte Klasse im Konstruktor dynamisch zu erstellen.

Das ist ja auch nicht notwendig, nur für die priviligierten Methoden, alle Anderen können auf die getter und setter zugreifen und im prototype deklariert werden.

Struppi.

[Timo "God's Boss" Reitz]

Das ist ja auch nicht notwendig, nur für die priviligierten Methoden, alle Anderen können auf die getter und setter zugreifen und im prototype deklariert werden.

Trotzdem unschön, hat man ein Array mit hundert Einträgen von Objekten, die jweils vier getter- und vier-setter-Methoden beinhalten, hat man schon achthundert Funktionsobjekte, hätte man auf die faktische Privatheit der Variablen verzichtet und sich mit einer formellen begnügt, wären es stattdessen nur acht.

[Struppi]

Das ist ja auch nicht notwendig, nur für die priviligierten Methoden, alle Anderen können auf die getter und setter zugreifen und im prototype deklariert werden.
Trotzdem unschön, hat man ein Array mit hundert Einträgen von Objekten, die jweils vier getter- und vier-setter-Methoden beinhalten, hat man schon achthundert Funktionsobjekte, hätte man auf die faktische Privatheit der Variablen verzichtet und sich mit einer formellen begnügt, wären es stattdessen nur acht.

Es sind so oder so 800 Objekte. Und spätestens, wenn man Vererben möchte kommt min mit prototype alleine sowieso nicht mehr aus.

Letztlich ging es in dem Thread um private Variabeln, entweder ich mache sie privat oder ich lasse es, dann brauch ich auch keine getter/setter Methoden.

Meine 2 Cent.

Struppi.

[Timo "God's Boss" Reitz]

Trotzdem unschön, hat man ein Array mit hundert Einträgen von Objekten, die jweils vier getter- und vier-setter-Methoden beinhalten, hat man schon achthundert Funktionsobjekte, hätte man auf die faktische Privatheit der Variablen verzichtet und sich mit einer formellen begnügt, wären es stattdessen nur acht.
Es sind so oder so 800 Objekte.

Wenn die getter- und setter-Methoden im Prototyp definiert sind, dann sind es nur 8 Funktionsobjekte.

Und spätestens, wenn man Vererben möchte kommt min mit prototype alleine sowieso nicht mehr aus.

Was meinst du, insbesondere in diesem speziellen Fall, damit?

Letztlich ging es in dem Thread um private Variabeln, entweder ich mache sie privat oder ich lasse es, dann brauch ich auch keine getter/setter Methoden.

Brauchen sowieso nicht, sinnvoll sind sie dennoch, siehe das Beispiel von Marc Reichelt.

[Struppi]

Es sind so oder so 800 Objekte.
Wenn die getter- und setter-Methoden im Prototyp definiert sind, dann sind es nur 8 Funktionsobjekte.

OK, ich hab das mal getestet und bei 50.000 Objekten (zugegeben Kleinen) merkt man tatsächlich einen Unterschied, vor allem im IE. Es muss sich halt jeder selbst überlegen wie streng er kapselt.

Und spätestens, wenn man Vererben möchte kommt min mit prototype alleine sowieso nicht mehr aus.
Was meinst du, insbesondere in diesem speziellen Fall, damit?

In welchem speziellen Fall? Es geht um OOP. wenn du mit prototype vererbst, ist das Basis Objekt immer das gleiche, was zu seltsaemn Effekten führen kann.

Letztlich ging es in dem Thread um private Variabeln, entweder ich mache sie privat oder ich lasse es, dann brauch ich auch keine getter/setter Methoden.
Brauchen sowieso nicht, sinnvoll sind sie dennoch, siehe das Beispiel von Marc Reichelt.

Ich hab's gelesen, aber das ist halt nicht (streng) OOP. Wie gesagt, das mag jeder selbst entscheiden ob und wie weit er sich daran hält, ich wollte lediglich auf die falsche Aussage, dass es in JS keine private Variabeln gäbe, Hinweisen.

Struppi.

[Struppi]

ja, ich weiß das.

wobei ich mich da jetzt wunder, weil du zuerst gemeint hast:

Eine private ObjektVariable würde ich mangels des private Schlüsselworts ..

var macht eine Variabel private.

Struppi.

[molily]

Hallo,

Auch in JavaScript gilt: Der Status eines Objekts wird konsistent gehalten.

Was bedeutet das (für Nicht-Informatiker wie mich)?

Mathias

[Volker Nebelung]

Aloha 'oe

Auch in JavaScript gilt: Der Status eines Objekts wird konsistent gehalten.

Was bedeutet das (für Nicht-Informatiker wie mich)?

Dass die if-Bedingung dieses Beispiels für alle Instanzen einer Klasse zentral und eindeutig verwendet wird.
Es kann also nicht auftreten, dass Objekt A aufgrund einer Nachlässigkeit in der Überprüfung der Geschwindigkeit eine Überlichtgeschwindigkeit zugewiesen bekommt, Objekt B dies aber ablehnt, obwohl beide Instanzen derselben Klasse sind.

Gruß, Volker

[Marc Reichelt]

Hallo molily,

Auch in JavaScript gilt: Der Status eines Objekts wird konsistent gehalten.

Was bedeutet das (für Nicht-Informatiker wie mich)?

Konsistenz im Sinne von OOP heißt:
Eine Klasse wird so geschrieben dass sie keinen fehlerhaften Zustand annehmen kann, wenn der Zustand über die Methoden geändert wird.

Das Beispiel "Spaceship" kann man noch erweitern, um zu zeigen wie dies gemeint ist.
Hier eine Auflistung beispielhafter Parameter eines Raumschiffs und deren erlaubte Werte:

speed       Gleitzahl, -LIGHTSPEED bis LIGHTSPEED
x           Ganzzahl, -MIN bis MAX
y           Ganzzahl, -MIN bis MAX
name        Name (String), minimal 1 Zeichen, maximal 42, erlaubte Zeichen: Buchstaben, Zahlen, Leerzeichen, ...

All diese Werte können über set-Methoden konsistent gehalten werden, sprich: Keiner der Werte wird zur Laufzeit einen fehlerhaften Wert erhalten, wenn die set-Methoden entsprechend geschrieben sind.

Die erlaubten Wertebereiche können sich außerdem im Laufe der Zeit ändern (beispielsweise sollen Raumschiffe in Version 2.0 des Spiels auch das max. 10fache der Lichtgeschwindigkeit annehmen dürfen).

Die set-Methoden könnten zudem nun noch bei fehlerhaften Eingaben Fehler produzieren, die dann vom aufrufenden Code abgefangen werden können.

So wird die Entwicklung effektiv in Kapseln unterteilt - und Fehler lassen sich einfacher finden und eliminieren.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[molily]

Hallo,

dass man keine Objekt Variablen benutzen, sondern alles über getter/setter Methoden bzw. Properties ansprechen soll.

Warum soll man das? Ernste Frage. Ich habe davon keine Ahnung. Es hat mich in JavaScript noch nie tangiert.

Sollte ich also auch dort meine Objekt Variablen in setter/getter Methoden kapseln?

Keine Ahnung, was erhoffst du dir dadurch? Warum Methoden verwenden, wenn du bloß einen Member ändern willst und keine Seiteneffekte anstoßen willst? Zum Selbstzweck?

Mathias

[Struppi]

Ich bin zwar auch nur Laie, hab' aber anfangs meiner Hobbykarriere am PC, mich viel mit C++ beschäftigt.

dass man keine Objekt Variablen benutzen, sondern alles über getter/setter Methoden bzw. Properties ansprechen soll.

Warum soll man das? Ernste Frage. Ich habe davon keine Ahnung. Es hat mich in JavaScript noch nie tangiert.

Das ist ein Grundkonzept in der OOP und nennt sich Kapselung.
In Java wird sowas auf die Spitze getrieben, meines Wissens ist es gar nicht möglich von aussen auf Objektattribute zu zugreifen. Ob und wie weit das wirklich sinnvoll ist, ist vermutlich unter richtigen Programmierern heftigst umstritten.

Struppi.

[thebach]

Hallo Struppi,

Ob und wie weit das wirklich sinnvoll ist, ist vermutlich unter richtigen Programmierern heftigst umstritten.

Also ich arbeite grade mit C# und beschäftige mich auch sonst mit OOP. IMHO geht es bei der Kapselung darum möglichst modular zu programmieren. D.h. einzelne Module sind soweit es geht voneinander abzugrenzen (zu kapseln). Dadurch können sie u.U. wiederverwendet werden.
Außerdem hilft es bei der Fehlersuche, da bei hoher Kapselung leichter auf Wechselwirkungen zwischen den Modulen geschlossen werden kann.

Grüße,
thebach

[Struppi]

Also ich arbeite grade mit C# und beschäftige mich auch sonst mit OOP. IMHO geht es bei der Kapselung darum möglichst modular zu programmieren. D.h. einzelne Module sind soweit es geht voneinander abzugrenzen (zu kapseln). Dadurch können sie u.U. wiederverwendet werden.

Das ist ja ok.

Außerdem hilft es bei der Fehlersuche, da bei hoher Kapselung leichter auf Wechselwirkungen zwischen den Modulen geschlossen werden kann.

Das mag auch ok sein, aber in JS (und anderen Sprachen) läßt sich leicht auf objekt.eigenschaft zugreifen und wenn man sich 100% sicher ist, dass diese Eigenschaft nie berechnet werden muss oder deren Gültigkeit woanders ermitteln werden kann, spricht da auch nichts dagegen die so verwenden. In JS z.b. gerne mal für Modulkonfigurationsparameter. Aber wie schon gesagt, das ist wohl so ein Streit, wie ob Windows besser wie Linux ist

Struppi.

[thebach]

Das mag auch ok sein, aber in JS (und anderen Sprachen) läßt sich leicht auf objekt.eigenschaft zugreifen und wenn man sich 100% sicher ist, dass diese Eigenschaft nie berechnet werden muss oder deren Gültigkeit woanders ermitteln werden kann, spricht da auch nichts dagegen die so verwenden. In JS z.b. gerne mal für Modulkonfigurationsparameter.

Die OOP-Unterstützung von JavaScript ist ja eher bescheiden, was aber eher als Vorteil zu sehen ist, da bei den meisten Anwendungsfällen von JS komplexe Objekthierarchien eher selten sind. JS ist eine Scriptsprache und als solche konzipiert.

Aber wie schon gesagt, das ist wohl so ein Streit, wie ob Windows besser wie Linux ist

OOP ist ein Konzept unter vielen. Ob man es anwenden kann/soll/will hängt natürlich sehr stark vom konkreten Anwendungsfall ab. Bei 3D-Programmierung (Spiele und so) wären solche Konstrukte fatal, weil sie viel zu lange brauchen um einen bestimmten Wert auszulesen. Dort wird auch direkt auf z.B. die Koordinaten zugegriffen. OOP ist auch nicht der Weisheit letzter Schluss, weil man bestimmte Sachen in OOP nicht direkt abbilden kann. Aspektorientierte Programmierung zum Beispiel hat auch seine Daseinsberechtigung.

Es ist halt ein ständiger Erweiterungsprozess.

thebach

[frankx]

Hellihello

Aspektorientierte Programmierung zum Beispiel hat auch seine Daseinsberechtigung.

Interessant. Beim Überfliegen fiel mir etwas auf, von dem ich letztlich, bei Programmierübungen dachte, es könne sinnvoll sein.

Nämlich zB. jeder Funktion eine Funktion zuordnen, dass sie sich beim starten beim Tracer/Logger/Ablaufkontrolle meldet und beim verlassen wieder.

Das hieße bei "normaler" Programmierung in PHP, dass
a) dies eben in jeder Funktion aufzurufen wäre
b) die Funktion ja nichtmal ihren eigenen Namen kennt, also der Funktionsname selbst auch noch zweimal an den Tracer übergeben werden müsste. Das macht ja wenig Sinn, bzw. zu viel Arbeit, das per Hand überall reinzukrakeln.

Wäre dass denn zB. mit Javascript-Hausmitteln möglich, jeder Funktion eine unterfunktion "anzuheften"? Für PHP sah ich in o.g. Arikel, dass es zahlreichere Versuche/Projekt gibt, das zu realisieren.

Dank und Gruß,

frankx

[thebach]

Die OOP-Unterstützung von JavaScript ist ja eher bescheiden, was aber eher als Vorteil zu sehen ist, da bei den meisten Anwendungsfällen von JS komplexe Objekthierarchien eher selten sind. JS ist eine Scriptsprache und als solche konzipiert.

Hab gerade den Link wiedergefunden, welchen ich noch anfügen wollte um zu zeigen wie wenig man in JS machen kann ;)
http://blog.nihilogic.dk/

thebach

[Timo "God's Boss" Reitz]

Die OOP-Unterstützung von JavaScript ist ja eher bescheiden, was aber eher als Vorteil zu sehen ist, da bei den meisten Anwendungsfällen von JS komplexe Objekthierarchien eher selten sind. JS ist eine Scriptsprache und als solche konzipiert.
Hab gerade den Link wiedergefunden, welchen ich noch anfügen wollte um zu zeigen wie wenig man in JS machen kann ;)
http://blog.nihilogic.dk/

Hat aber nichts mit der Aussage über Objektorientierung zu tun, da man ein solches Spiel theoretisch auch komplett mit funktionaler oder imperativer Programmierung erstellen könnte.

[Don P]

Hallo,

Die OOP-Unterstützung von JavaScript ist ja eher bescheiden [...]
Hab gerade den Link wiedergefunden, welchen ich noch anfügen wollte um zu zeigen wie wenig man in JS machen kann ;)
http://blog.nihilogic.dk/
Hat aber nichts mit der Aussage über Objektorientierung zu tun, da man ein solches Spiel theoretisch auch komplett mit funktionaler oder imperativer Programmierung erstellen könnte.

Wie? Nichts mit OOP zu tun?

Das ist ja so, als wenn jemand behauptet, ein Ferrari sei kein Auto, und wenn man dann damit 1000 km weit fährt, kommt als Argument "das hat nichts mit Auto zu tun, man könnte ja die 1000 km auch zu Fuß gehen".

*kopfschüttel*

Gruß, Don P

[Timo "God's Boss" Reitz]

Die OOP-Unterstützung von JavaScript ist ja eher bescheiden [...]
Hab gerade den Link wiedergefunden, welchen ich noch anfügen wollte um zu zeigen wie wenig man in JS machen kann ;)
http://blog.nihilogic.dk/
Hat aber nichts mit der Aussage über Objektorientierung zu tun, da man ein solches Spiel theoretisch auch komplett mit funktionaler oder imperativer Programmierung erstellen könnte.
Wie? Nichts mit OOP zu tun?

Ich habe geschrieben, dass es nichts mit der Aussage über Objektorientierung zu tun hat. Zweifelsfrei ist das Mario-Kart-Spiel beeindruckend, in dem Spiel ist auch objektorientierte Programmierung zum Einsatz gekommen. Es ist aber nicht unbedingt ein Beispiel für "spektakuläre OOP-Unterstützung", in dieser Hinsicht ist es (nach grober Durchsicht des Codes) eher Standard. Insofern ist die Behauptung, dass die OOP-Unterstützung von JavaScript eher bescheiden sei, nicht durch das Spiel widerlegt.

Das ist ja so, als wenn jemand behauptet, ein Ferrari sei kein Auto, und wenn man dann damit 1000 km weit fährt, kommt als Argument "das hat nichts mit Auto zu tun, man könnte ja die 1000 km auch zu Fuß gehen".

Vergleiche sind ausnahmslos schlecht und überflüssig.

[Don P]

Hallo,

Insofern ist die Behauptung, dass die OOP-Unterstützung von JavaScript eher bescheiden sei, nicht durch das Spiel widerlegt.

Dann möchte ich doch die Behauptung aufstellen, dass deine Kenntnisse von Javascript eher becheiden sind. Das ist auch gleich durch deine Aussage bewiesen.

Was immer du unter richtigem OOP verstehst – wahrscheinlich das Hantieren mit Klassen à la Java, mit get/set-Methoden usw. – JavaScript arbeitet mit Prototypen und prototypischer Vererbung. Objektorientierter geht es nicht.

Vergleiche sind ausnahmslos schlecht und überflüssig.

Solche Pauschalurteile erst recht.

Gruß, Don P

[Timo "God's Boss" Reitz]

Insofern ist die Behauptung, dass die OOP-Unterstützung von JavaScript eher bescheiden sei, nicht durch das Spiel widerlegt.
Dann möchte ich doch die Behauptung aufstellen, dass deine Kenntnisse von Javascript eher becheiden sind. Das ist auch gleich durch deine Aussage bewiesen.

Dann beweise deine Behauptung. Unten schreibst du von Prototypen und prototypischer Vererbung, beides ist mir hinlänglich bekannt. Kommt es im Spiel vor? Nein! Also widerlegt das Spiel nicht die Behauptung der bescheidenen OOP-Unterstützung von JavaScript. Dass ich das erkannt habe, ist also nun schon ein Beweis für meine bescheidenen JavaScript-Kenntnisse?

Was immer du unter richtigem OOP verstehst – wahrscheinlich das Hantieren mit Klassen à la Java, mit get/set-Methoden usw. – JavaScript arbeitet mit Prototypen und prototypischer Vererbung. Objektorientierter geht es nicht.

Schön, warum erzählst du mir das? Ich habe gar nicht behauptet, dass die OOP-Unterstützung in JavaScript bescheiden ist, das war thebach.

Vergleiche sind ausnahmslos schlecht und überflüssig.
Solche Pauschalurteile erst recht.

Pauschalurteile sind, wenn sie einfach richtig sind, gut und nützlich. So wie dieses. Entweder man kann etwas am Betrachtungsgegenstand zeigen oder nicht. Wenn man es zeigen kann, braucht man keinen Vergleich, kann man es nicht zeigen, kann ein Vergleich nur falsch sein.

[thebach]

Schön, warum erzählst du mir das? Ich habe gar nicht behauptet, dass die OOP-Unterstützung in JavaScript bescheiden ist, das war thebach.

Ja entschuldigt bitte. Ich ziehe meine pauschale Behauptung zurück und stelle mich für den Rest des Threads in die Ecke. *ascheüberhauptschütt*

thebach