getter und setter

[JockelFragtNach]

Hallo!

Ich habe gerade diesen Artikel auf JavaWorld bezüglich
getter und setter Methoden gelesen.

Kurz zusammengefasst sagt der Autor, dass man mit getter- und setter-Methoden sparsam umgehen sollte, da man
Daten und Implementierung des Objektes verbergen sollte.

Es gäbe jedoch einige Fälle, beispielsweise JavaBeans, in denen getter- und setter-Methoden für Eigenschaften
eingeführt worden seien. Der Grund sei aber in erster Linie, dass die Tools mit diesen getter- und setter-Methoden
arbeiten.

Folgende Klasse genügt der Java-Bean-Spezifikation und dieses Muster von settern oder Gettern nutzen wir auch bei der Verwendung von Hibernate oder Spring:

Class A {
  private Property property;
 
  public setProperty(Property property) {
    this.property = property;
  }

  public Property getProperty() {
    return this.property;
  }
}

und folgende Klasse scheinbar nicht, hat aber die gleiche Semantik:

Class A {
  public Property property;
}

Damit stellt sich für mich folgende Frage:

Wozu eigentlich die getter- und setter-Methoden in den Java-Beans?


Danke schon mal im Voraus

Jockel

 

[Wildcard]

Da in Java immer getter und setter dem direkten Zugriff auf die Member vorzuziehen sind.

 

[André Uhres]

http://www.java-forum.org/de/viewtopic.php?p=273655#273655

 

[Hilefoks]

Ich denke getter und setter erleichtern den Zugriff, da man ohne diese Reflection einsetzen müsste bzw. benutzt wird. Reflection ist aber sicher zum einen um einiges langsamer, aber vor allem auch schwerer für Einsteiger - daher wird Sun das getter/setter Idiom wohl eingeführt haben.

MfG,
Hilefoks

P.S: Dein Link ist kaputt.
Edit: andré und wildcard waren schneller...

 

[Wildcard]

@Hilefoks
auch auf die getter und setter wird per Reflection zugegriffen.

 

[Hilefoks]

@Hilefoks
auch auf die getter und setter wird per Reflection zugegriffen.

Ja - mh - ich habe mich blöd ausgedrückt... ich meinte nicht den Zugriff durch Tools. Ich meinte eher das getter/setter für Programmierer (speziell Anfänger/Einsteiger) einfacher sind als Reflection. Für richtig sauberes OOP (jenes aus der Lehre) dürfte es aber keine setter/getter geben (was der Artikel wohl auch sagt).

MfG,
Hilefoks

 

[Wildcard]

:?:

 

[Hilefoks]

public class X {
    private String foo="Bar";

    public String getFoo() { return foo; }
}

Diese Klasse verstößt, fragt man z.B. einige Prof., gegen das OOP Prinzip das sagt man muss die Implementierungsdetails einer Klasse verbergen. Warum? Weil die get-Methode eine String zurückliefert. Damit ist das Implementierungsdetail das foo ein String ist, öffentlich bekannt. Möchte der Klassen-Author nun die Klasse verändern und anstelle eines Strings eine eigene Klasse schreiben gibt getFoo keinen String mehr zurück - und wir müssen unser Programm anpassen (dieses Beispiel hinkt, ich weiß). Daher halten jene Personen das getter/setter Idiom für einen Fehler, den Sun nur eingeführt hat, weil Einsteiger/Umsteiger damit leichter zurecht kommen als wenn sie Reflection nutzen müssten. Im Allgemeinen verweißen solche Leute im übrigen immer auf Smalltalk.

MfG,
Hilefoks

 

[merlin2]

Das leuchtet mir ein - aber Java ist voll von Gettern und Settern, deren Befürworter auch sehr gute Argumente haben.
Smalltalk? Warum sollte Java alles aus Smalltalk übernehmen (dann wäre Java doch keine eigene Sprache mehr)?

 

[Hilefoks]

Smalltalk? Warum sollte Java alles aus Smalltalk übernehmen (dann wäre Java doch keine eigene Sprache mehr)?

Na ja - Smalltalk ist nur eine Wurzel - eine weitere wäre C++.
Aus C++ kommt auch die Art wie man Methoden aufruft, was letztlich ein Erbe aus C ist - und somit von ~1965. Ich finde nichts schlechtes an diesem Prinzip - Smalltalk macht es aber gänzlich anders - und eher der Lehre entsprechend (oder orientiert sich die Lehre an Smalltalk).

MfG,
Hilefoks

 

[merlin2]

Welche Lehre? OOP? C war doch nie darauf, ausgerichtet objektorientiert zu sein?

 

[Hilefoks]

Welche Lehre? OOP? C war doch nie darauf, ausgerichtet objektorientiert zu sein?

Ja. Als Ken und Dennis C entwickelten entstand zwar schon Simular (erste OOP Sprache), die kannten Sie wohl aber noch nicht. ;-)

 

[merlin2]

Simular war die erste objektorientierte Sprache? Ich dachte immer die erste objektorientierte Sprache sei Smalltalk gewesen, lasse mich aber gerne belehren.

 

[Tobias]

WTF?

Weil die get-Methode eine String zurückliefert. Damit ist das Implementierungsdetail das foo ein String ist, öffentlich bekannt.

Durch den Getter wird das Implementierungsdetail, das foo ein String ist, doch gerade verborgen(!). Klingt komisch, ist aber so. Schließlich könnte ich auch schreiben:

private MeineMerkwuerdigeKlasse foo;

public String getFoo() {
    return foo.toString();
    // oder return foo.computeString();
    // oder return foo.doSomething();
}

mpG
Tobias

 

[Hilefoks]

Simular war die erste objektorientierte Sprache? Ich dachte immer die erste objektorientierte Sprache sei Smalltalk gewesen, lasse mich aber gerne belehren.

Simular war vor Smalltalk. Simular ist in den 60er entstanden und 67 veröffentlicht worden (ich glaube 63 der erste Prototyp-Compiler). Smalltalk ist erst in den 70 entstanden und wurde 1980 veröffentlicht. Deshalb heißt Simular auch Simular-67 und Smalltalk Smalltalk-80. ;-)

Allerdings war einer der Entwickler von Smalltalk derjeniger der den Begriff "objektorientierung" erfunden hat (und man könnte somit sagen das Smalltalk die erste objektorientierte Sprache war, weil Simular ja so nicht bezeichnet wurde ;-) ).

MfG,
Hilefoks

 

[Hilefoks]

Durch den Getter wird das Implementierungsdetail, das foo ein String ist, doch gerade verborgen(!). Klingt komisch, ist aber so....

Und weil ich wusste das jemand so kommt hatte ich folgendes geschrieben:

(dieses Beispiel hinkt, ich weiß)

;-)

 

[Tobias]

Mir ist auch das Originalbeispiel aus dem Artikel (int zurückgegeben, jetzt Erweiterung des Wertebereichs auf long) nicht als "evil" klar geworden. Ja, das ist eine dämliche Situation, aber kein Fehler des Accessors an sich, sondern ein Designproblem. Wobei ich mit der Kernaussage des Artikels, Properties private zu halten (und dann auch nicht über unnötige Getter zugänglich zu machen), durchaus konform gehe...

mpG
Tobias

 

[Hilefoks]

Ja, das ist eine dämliche Situation, aber kein Fehler des Accessors an sich, sondern ein Designproblem.

Aber genau darum geht es ja... mit getter/setter verlässt man sich auf Implementierungs-Details, womöglich eines fremden Programmierers. Man nehme an man verwendet eine fremde, kommerzielle Bibliothek. Diese bekommt ein Update auf das man unbedingt umsteigen muss (z.B aus Sicherheitsgründen), hat aber einige getter und setter verändert. Nun muss man seinen eigenen Code anpassen, Adapter schreiben, etc.

Und eben das soll, so die Lehrmeinung, mit OOP nicht passieren. Jede Klasse soll verändert werden können ohne das irgendeine andere Klasse dadurch ebenfalls angepasst werden muss. Damit das halbwegs möglich ist benötigt man entweder ein Modell wie Smalltalk es hatte (es werden Nachrichten auf die Objekte geschmissen die diese verarbeiten, oder auch nicht) oder man muss seinen Code von solchen Implementierungsdetails fernhalten, also Objekte per Reflection analysieren.

Aber: das ist nur die Lehrmeinung bzgl. OOP (aka. akademischer Scheiß). Es gibt fast keine Sprache die ein Paradigma wirklich konsequent umsetzt und dabei auch noch erfolgreich oder benutzbar ist.

MfG,
Hilefoks

 

[Murray]

Wenn in dem Artikel die Rede davon ist, dass Setter und Getter "böse" sind, dann ist damit sicher nicht gemeint, dass es besser wäre, stattdessen die entsprechenden Member einfach public zu setzen; ich denke dass wenn eine Zugriff auf Member von externen Klassen aus möglich sein soll, Accessor-Methoden i.d.R. die bessere Wahl sind.

Im Sinne der Objektorientierung wäre es natürlich wünschenswert, alle Operationen, die auf einem Satz von Daten definiert sind, auch in der jeweilgen Klasse zu implementieren, damit man keine Implementierungsdetails exponiert - m.E. ist das aber nicht immer der beste Weg. Wenn ich z.B. eine Klasse definiere, in der zusammengehörige Daten (wie z.B. eine Person mit Vor- und Nachnamen, Geburtsdatum etc.) auftauchen, dann möchte ich nicht gezwungen sein, in der gleichen Klasse auch alle Funktionen zu codieren, die auf einzelne Member zugreifen (z.B. Speichern und Lesen aus einer Datenbank oder Anzeiger in einer GUI); vielmehr muss ich anderen Code-Teilen (z.B. in der GUI- oder in der Persistenzschicht) die Chanche geben, an die konkreten Daten heranukomen - und dazu dienen eben die Accesoor-Methoden.

Eine konkrete Empfehlung könnte sein, nicht schlafwandlerisch für jedes Member Setter und Getter zu implementieren (bzw. von der IDE generieren zu lassen), sondern dies auf die Stellen zu beschränken, wo die Member unbedingt von anderen Klassen referenziert werden müssen.

 

[Tellerrand]

Und eben das soll, so die Lehrmeinung, mit OOP nicht passieren. Jede Klasse soll verändert werden können ohne das irgendeine andere Klasse dadurch ebenfalls angepasst werden muss.

Das ist nur faktisch unmöglich. Eine Klasse wird immer nur begrenzt änderbar sein ohne das es Auswirkungen auf den Rest des Programms hat. Da ändert Smalltalk auch nichts dran. Wenn eine Smalltalk Klasse eine andere Nachricht verlangt wie bisher, dann muss auch der Rest des Codes angepasst werden. damit das Programm wieder funktioniert. Bisher habe ich von dieser Lehrmeinung noch nichts gehört und kann mir schlecht vorstellen wie eine Programmiersprache sämtliche Codeänderungen wegstecken soll.
(Smalltalk ersetzt hier doch nur das Wort Methode durch Nachricht. Wenn eine Klasse auf einmal andere Nachrichten verarbeitet, dann muss ich auch da meinen Code ändern)
Getter und Setter wird man immer in OOP brauchen, Klassen bestehen auch oft aus Attributen die man ändern und ausgeben muss und wie sollte man das machen wenn nicht über den direkten Zugriff, oder den indirekten mittels Getter/Setter?

Anderst ausgedrückt,
Interface Person defineirt eine Methode String getName(), eine Klasse implementiert dies, wo liegt hier die Information über die Implementierung?
Die Implementierung ist undebkannt, das einzige was man kennt ist die Definition aus dem Interface.

Ich gebe dir natürlich recht darin, dass diese auto generierten (nicht im Sinne von OOP eingesetzten) Getter und Setter mehr verraten als sein sollte. Nur das ist erst durch die ganzen lustigen Frameworks geschehen. Die verlangen oft getter und setter um Klassen performant analysieren zu können, oder auch Stellvertreter Objekte zu produzieren... eigentlich schade.

 

[Hilefoks]

Wenn in dem Artikel die Rede davon ist, dass Setter und Getter "böse" sind, dann ist damit sicher nicht gemeint, dass es besser wäre, stattdessen die entsprechenden Member einfach public zu setzen

Oh Gott - natürlich nicht! Lese meinen Beitrag bitte nochmal - da steht kein Wort von public member. ;-)
Auch inpliziert "keine getter/setter" nicht, das man nur noch eine grosse Klasse schreiben kann. Du solltest meinen Beitrag oder den verlinkten Artikel nochmal aufmerksam lesen... ;-)

Das ist nur faktisch unmöglich.

Jo - möchte ich nicht bestreiten.

...Da ändert Smalltalk auch nichts dran. Wenn eine Smalltalk Klasse eine andere Nachricht verlangt wie bisher, dann muss auch der Rest des Codes angepasst werden. damit das Programm wieder funktioniert. Bisher habe ich von dieser Lehrmeinung noch nichts gehört und kann mir schlecht vorstellen wie eine Programmiersprache sämtliche Codeänderungen wegstecken soll.
(Smalltalk ersetzt hier doch nur das Wort Methode durch Nachricht. Wenn eine Klasse auf einmal andere Nachrichten verarbeitet, dann muss ich auch da meinen Code ändern)

Da verstehst du Smalltalk nicht. Zum einen verlangt keine Klasse eine Nachricht und zum anderen ist eine Nachricht in Smalltalk wirklich etwas ganz anderes als eine Methode in Java/C++/etc..

Getter und Setter wird man immer in OOP brauchen, Klassen bestehen auch oft aus Attributen die man ändern und ausgeben muss und wie sollte man das machen wenn nicht über den direkten Zugriff, oder den indirekten mittels Getter/Setter?

Smalltalk hat bereits 1980 bewiesen das man keine getter/setter benötigt.

Anderst ausgedrückt,
Interface Person defineirt eine Methode String getName(), eine Klasse implementiert dies, wo liegt hier die Information über die Implementierung?
Die Implementierung ist undebkannt, das einzige was man kennt ist die Definition aus dem Interface.

Die Implementierung ist in so fern bekannt, als das bekannt ist das Name ein String ist.

MfG,
Hilefoks

P.S: Bitte versteht mich nicht falsch! Ich selbst bin nicht der Meinung das getter/setter "böse" sind und ebenso wenig halte ich im Allgemeinen von Single-Paradigmen Sprachen.

 

[Tellerrand]

Da verstehst du Smalltalk nicht. Zum einen verlangt keine Klasse eine Nachricht und zum anderen ist eine Nachricht in Smalltalk wirklich etwas ganz anderes als eine Methode in Java/C++/etc..

Trotzdem kannst du nicht abstreiten, dass du in Smalltalk Code anpassen musst, wenn du in irgendeiner Klasse zu viel Änderungen durchführst.
Wie lustig wäre denn das, wenn ich einfach simpel Code aus einer Klasse löschen kann und das Programm funktioniert trotzdem. Freut sich der Kunde, hab ich Fehlerquellen und Speicherplatz eingesparrt :shock:

Smalltalk hat bereits 1980 bewiesen das man keine getter/setter benötigt.

Verrate mir wie man sonst ein Attribut einer Klasse ändert, wenn nicht über den direkt Zugriff oder den indirrekten mittels einer Funktion?
Wenn man Attribute von außen veränderbar lassen will, dann braucht man irgendeine vorgeschriebene Art wie man das macht. Ein Programmierer kann ja schlecht sagen "Hey ich hab keine Ahnung welche public Funktionen und Methoden die Klasse bietet oder wie man überhaupt auf eine Klasse zugreift, aber ich arbeite trotzdem mir ihr und es funktioniert"
Genauso in Smalltalk, wenn ich dir sage das ist Klasse x, die ist für Netzwerkkommunikation gut, dann bis du noch nicht in der Lage diese zu nutzen.
Verrate mir also wie man ohne eine Form von Getter/Setter und ohne den direkten Zugriff auf ein Attribut dieses verändern will.
Beispiel die Klasse Person, die einen Namen (egal in welcher Form) hat. Wie änderst du den?
Und noch besser, wie greift ein anderer Teil auf den Namen zu?

Die Implementierung ist in so fern bekannt, als das bekannt ist das Name ein String ist.

Sicher? Woher willst du wissen, dass das Attribut ein String ist?
Das einzige was bekannt ist, dass dort eine Methode existiert die einen String zurückliefert, alles andere ist Vermutung.
Getter und Setter sind richtig angewand völlig normal, Methoden zum verändern von Objektzuständen und Eigenschafften.


Das einzige Problem was entsteht ist, dass viele Programmierer Getter und Setter generell setzen (müssen). Wodurch sie natürlich nichtmehr im Sinne von OOP sind. Aber ansonsten sehe ich keinen Punkt an dem ein setBliBla() in Kombination mit einem getBliBla() OOP Paradigmen brechen würde.

 

[Hilefoks]

Trotzdem kannst du nicht abstreiten, dass du in Smalltalk Code anpassen musst, wenn du in irgendeiner Klasse zu viel Änderungen durchführst.
Wie lustig wäre denn das, wenn ich einfach simpel Code aus einer Klasse löschen kann und das Programm funktioniert trotzdem. Freut sich der Kunde, hab ich Fehlerquellen und Speicherplatz eingesparrt :shock:

So natürlich nicht...

Verrate mir wie man sonst ein Attribut einer Klasse ändert, wenn nicht über den direkt Zugriff oder den indirrekten mittels einer Funktion?

Es geht nicht darum nicht auf ein Attribut zugreifen zu können - es geht nur darum nicht von Typ und Implementierungsdetails abhängig zu sein... und auch in Java macht man das -> Reflection!

Sprachen wie Smalltalk und Ruby haben aber grundsätzlich kein getter/setter Idiom - dort ist es normal zur Laufzeit die fähigkeiten einer Klasse zu ermitteln. Es diene zur Veranschaulichung dazu ein Beispiel aus der Wikipedia, geschrieben in Ruby:

class Auto
  def beschleunigen
    puts 'BrumBrumBrum'
  end
end

class GutesAuto < Auto
  def bremsen
    puts 'Quietsch'
  end
end

def auto_abbremsen(auto)
  puts 'Auto wird abgebremst...'
  if auto.respond_to?(:bremsen)
    auto.bremsen
  else
    puts 'Keine Bremse vorhanden!'
  end
end

auto1 = Auto.new
auto2 = GutesAuto.new
auto_abbremsen(auto1)
auto_abbremsen(auto2)

In diesem Beispiel werden Nachrichten verschickt - es werden keine Methoden der Klasse aufgerufen (auch wenn sie wie Methoden aussehen). Mit respond_to kann man erfragen ob eine Klasse eine Nachricht auch verarbeitet...

Die Implementierung ist in so fern bekannt, als das bekannt ist das Name ein String ist.

Sicher? Woher willst du wissen, dass das Attribut ein String ist?

Wie bereits erwähnt hatte ich deshalb auch geschrieben das dieses Beispiel hingt. Es kann doch aber nicht so schwer dieses Beispiel ein wenig zu abtrainieren? Aber vielleicht ist der verlinkte Artikel an dieser Stelle etwas ausführlicher und besser verständlich...

Ein empfehlenswerter Vortag zur OOP-Lehre findet sich übrigens hier -> http://ulm.ccc.de/ChaosSeminar/2007/02_Objektorientierung

MfG,
Hilefoks

 

[kleiner_held]

Meine Aussage zu Punkten wie:
- es geht nur darum nicht von Typ und Implementierungsdetails abhängig zu sein... und auch in Java macht man das -> Reflection!
- zur Laufzeit die fähigkeiten einer Klasse zu ermitteln
(sorry fuer die bruchstuckhaften Zitate)
lässt sich in diesem Satz zusammenfassen:

Reflection is evil

Es mag ja schön sein zu sagen, je unspezifischer ich meine Klassen halte, desto besser wartbarer und veränderbarer ist mein Design. Aber dadurch verliere ich meine ganze Typensicherheit, eine der Kern-Eigenschaften von Java. Im Endeffekt geht das ganze massiv auf Kosten der compile time safety und das alles fliegt mir dann zur Laufzeit um die Ohren.

Beispiel:
In deinem Ruby code fliegt dann halt: 'Keine Bremse vorhanden!' was für den der im Auto sitzt ein massives Problem darstellt. In Java lässt sich der Code mit einem Auto ohne Bremsen nicht compilieren.

Wenn ich mich zwischen compile time safty und Wartbarkeit durch data abstraction entscheiden muss, wähle ich immer das erstere. Der Grund dafür ist kein "theoritisch muss es so sein" sondern ein "nach meiner Erfahrung ist Reflection immer eine riesige Fehlerquelle und die Fehler merkt man immer erst zu spät"

 

[Hilefoks]

Meine Aussage zu Punkten wie...

Full ACK - Reflection ist nur theoretisch eine Lösung - praktisch funktioniert das nicht. Allerdings ist das ganze Thema "getter/setter sind böse" auch nur theoretisch - wie gesagt, mein Standpunkt dazu: "akademischer Scheiß" ;-)

Allerdings finde ich diesen "akademischen Scheiß" sehr interessant. Man kann solche Sachen nicht in der Praxis 1:1 umsetzen, allerdings kann man dennoch immer ein paar Sachen aus diesen Ideen lernen. Den Java Sprachdesigner waren Smalltalk, C++ und Co. ja sehrwohl bekannt - dennoch haben sie sich für ein anderes Sprachdesign entschieden. Und dafür hatten sie durchaus gute Gründe. Wenn man aber sowohl die "Lehre" kennt und versteht als auch die konkrete Umsetzung in einer bestimmten Sprache kann man sich die Frage stellen: Warum haben die es anders gemacht. Wenn man sich solche Fragen stellt und sich damit beschäftigt kann man einiges lernen! ;-)

MfG,
Hilefoks

 

[Tellerrand]

Du willst also darauf hinaus, dass ich Objekte alle gleich behandlen kann und irgendwann nachgucke ob sie Methode xy implementieren?
Das ist aber doch kein Implementierungsdetail sondern eine Typinformation.
Lustig wird es, wenn ich mich beschwere, dass man dort im Ruby Code an der Stelle auto_abbremsen(auto2) genauso davon ausgeht, dass es die Methode auto_abbremsen im Typ x gibt. Das sollte man doch bitte erstmal herausfinden.
Da würde deine OOP Theorie auf ein "Ja ich ruf einfach Methoden irgendwie auf und schau ob es dann funktioniert" hinauslaufen und das ist meiner Meinung nach nicht im Sinne von OOP.

Vielleicht haben wir da auch eine Unterschiedliche Lehre von OOP genossen, aber ich bezweifle stark, dass du hier von einem allgemein anerkanntem Paradigma sprichst, welches lautet "Typinformationen und Klassendefinitionen müssen geheim bleiben"
Von Implementierungsdetails ist man gerne unabhängig, aber vom Typ ...

 

[kleiner_held]

Meine Meinung zu solchen Artikeln ist halt, dass man sie mal an der Praxis messen soll. Wenn ich mir überlege was ich schon für Artikel mit der Kernaussage "... in Java is evil" gelesen habe, dann frage ich warum es überhaupt noch Querköpfe gibt, die diese Sprache verwenden - wenn man alles wegläßt was evil ist, bleibt nichts übrig.

paar Beispiel gefällig?
- das hier behandelte "getter and setter methods are evil"
- Why extends is evil (auch in deinem Artikel verlinkt, ich kenne noch eine andere Version)
- Mutability is evil (der Autor meinte, man sollte nur mit immutable Klassen arbeiten, alle Setter weglassen, die Attribute im Konstructor übergeben und wenn man was verändern will, ein neues Objekt mit anderen Attributen anlegen)
- Reflection is evil (der Meinung kann ich mich sogar zum Teil anschließen)
- primitive Datentypen sind sowieso evil
...

Da es aber auch noch allgemeinere Pamphlete gibt, ala PHP is evil oder noch allgemeiner Scripting languages are evil, scheint das wohl allgemein ein beliebtes Hobby in der Programmiersprachenlandschaft zu sein. Was will man auch über Programmiersprachen schreiben, außer den ergiebigen Themen "Was es schönes neues gibt" und "Warum das existierende grottenschlecht ist"?
Deswegen bin ich inzwischen der Meinung, nur weil einer einen Artikel schreibt und es damit vielleicht sogar in ein Online-Magazin schafft, hat er noch lange nicht die Weisheit mit Löffeln gefressen

Allerdings gebe ich Dir recht, dass man auch immer mal über den Tellerrand ( :lol: ) schauen sollte - den Horizont erweitern schadet nie.

 

[Triebi]

Vorher:

public class PublicMember {
    public int member;
}

public class Getter {
    private int member;
    public int getMember() {
       return member;
    }
}

Nachher:

public class PublicMember {
    public long member;
}

public class Getter {
    private long member;
    public long getMember() {
       return member;
    }
}

Verwendung:

public class Foo {
    public void doSomething(int para) { /* ... */ }

    public static void main(String[] args) {
        new Foo().doSomething(new PublicMember().member);
        new Foo().doSomething(new Getter().getMember());
    }
}

Wer bestimmte Dinge einer Klasse öffentlich zugänglich macht, egal auf welche Weise, schränkt seine Möglichkeiten für Änderungen auf jeden Fall ein. Gerade dieses Beispiel mit dem int, welches plötzlich zum long wird, ist IMHO schlecht gewählt, weil dies nicht (nur) die Klasseninterna, sondern auch die öffentliche API betrifft. In obigem Beispiel funktioniert doSomething(int) mit keiner der beiden neuen Versionen von PublicMember und Getter. Warum? Weil die neue API inkompatibel mit der alten ist. Daran ändert auch die Art des Zugangs zum entsprechenden Feld nichts.

 

[Tellerrand]

Interessant ist noch wie mit der Typsicherheit und den Typinformationen Implementierungsdetails unwichtiger werden.

Noch zu dem Ruby Beispiel von oben
Wenn ich eine neue Funktion implementieren will die autos bremsen (wie die Funktion auto_abbremsen(auto)), dann muss ich wissen, dass die Klassen aller Autos eben auf das Schlagwort "bremsen" reagieren und nicht auf "abbremsen", eine Typinformation. Andernfalls würde meine Funktion niemals mit den vorhandenen Autos funktionieren.

Nun umgekehrt, will ich ein neues Auto in den bestehenden Code einfügen so muss ich wissen, dass die Funktion "auto_abbremsen(auto)" wie folgt implementiert ist "auto.bremsen". Ansonsten würde ich vielleicht nicht bremsen als Funktionsnamen bei der neuen Autoklasse nehmen sondern "abbremsen". Implementierungsdetails müssen bekannt sein.

Und genau deshalb bezweifle ich hier die ganze Zeit, dass es gängige OOP Lehre ist Typinformationen zu verbergen.
Die Informationen über den Typ, aus Java z.B. ein Interface KannBremsen welches die Methode bremsen() vorschreibt macht es unnötig zu wissen wie auto_abbremsen(KannBremsen bremsbaresAuto) implementiert ist.

 

[semi]

Die C# Lösung für Getter/Setter ist sehr elegant. Man definiert einfach Properties und
was bei Lesen/Schreiben zugewiesen/zurückgegeben wird.
z.B.

private bool enabled;

public bool Enabled {
   get {
      return enabled;
   }
   set {
      enabled = value;
   }
}


// Zugriff drauf

foo.Enabled = true;

if (foo.Enabled) {
   ...
}