[abgespalten aus: http://forum.byte-welt.net/news-und-schlagzeilen-aus-der-it-welt/news/java/16804-5-java-9-features-die-die-softwareentwicklung-veraendern-werden.html ]
Ich kann immer noch nicht verstehen, warum ein Feature wie Properties (aus z.B. C#) nicht auch integriert werden. Keine Getter/Setter - das wäre doch mal ein Feature!
[quote=Sym]Keine Getter/Setter - das wäre doch mal ein Feature![/quote]Nur weil sie nicht so heißen bedeutet das nicht, dass es keine sind…
Für mich wäre so ein Feature nur dann sinnvoll, wenn ich eine Klasse explizit als DTO kennzeichnen könnte und dann einen Compilefehler erhielte, wenn mehr als hashcode() equals() und toString() implementiert würde.
bye
TT
[QUOTE=Timothy_Truckle]Nur weil sie nicht so heißen bedeutet das nicht, dass es keine sind…
Für mich wäre so ein Feature nur dann sinnvoll, wenn ich eine Klasse explizit als DTO kennzeichnen könnte und dann einen Compilefehler erhielte, wenn mehr als hashcode() equals() und toString() implementiert würde.
bye
TT[/QUOTE]
Verstehe ich nicht. Warum sollte es für normale Klassen nicht auch sinnvoll sein? C# macht es wunderbar vor. Es gibt nämlich auch semantische Unterschiede zwischen Gettern/Settern und Property-Zugriffen.
*** Edit ***
Ist eines der (wenn nicht das) erwähnenswerten Features. Es hat schon Gründe, warum Java9 bisher noch nicht so in Erscheinung getreten ist.
[quote=Sym]Verstehe ich nicht. Warum sollte es für normale Klassen nicht auch sinnvoll sein?[/quote]Getter und Setter fördern “feature envy”, d.h. das interne Eigenschaften des Objekts außerhalb des Objects maniputiert (und zurückgeschrieben) werden, was einen Verstoß gegen das oberste OO-Prinzip “information hiding” ist. (OK, ok! Ich weiß, dass ich mit dieser Einstellung hier zur Minderheit gehöre…)
In java weiß ich explizit, wo sowas passieren kann, weil ich die Getter/Setter in der Klasse sehe, bzw kann es durch Löschen dieser unterbinden.
In DTO’s sind Getter/Setter wie gesagt durchaus akzeptbel. Sonnst ist es problematisch, Daten zwischen verschiedenen Schichten oder auch nur verschiednen Klassen auszutauschen. Aber DTOs dürfen eben keine Geschäftslogik enthalten.
bye
TT
Also wenn schon, dann mal richtig - aber ich rechne nicht damit -
Ein einfaches Konstrukt wie die case classes von Scala (automatisch immutable, getter/setter unnötig bzw. versteckt, hashcode, equals, toString automatisch, copy-Methode,…)
Und endlich mal mit dem Properties-Alptraum aufräumen (Beans mit getter/setter per Namenskonvention, die neuen Java-FX-Properties, irrsinnige Wrapper für die primitiven Typen) und einen neuen, stabilen, universalen Mechanismus für das Binding schaffen: heute gibt es das Beans-Binding, JavaFX-Binding, JPA, etc.: der Shit wird irgendwann zu viel
[quote=Bleiglanz]der Shit wird irgendwann zu viel[/quote]Das Problem von Java an dieser STelle ist die Rückwärtskompatibilität. Java muss immer auch legacy-Bytecode unterstützen.
Eine neue Programmiersprache könnte das alles gleich viel geradlieniger lösen.
bye
TT
[QUOTE=Timothy_Truckle;119919]Getter und Setter fördern “feature envy”, d.h. das interne Eigenschaften des Objekts außerhalb des Objects maniputiert (und zurückgeschrieben) werden, was einen Verstoß gegen das oberste OO-Prinzip “information hiding” ist. (OK, ok! Ich weiß, dass ich mit dieser Einstellung hier zur Minderheit gehöre…)
In java weiß ich explizit, wo sowas passieren kann, weil ich die Getter/Setter in der Klasse sehe, bzw kann es durch Löschen dieser unterbinden.[/QUOTE]
Ich weiß nicht, ob Du Dich mit C# Properties auskennst, aber auch hier kannst Du die Sichtbarkeit einschränken - nur halt an der Deklaration des Members direkt. Und ein Get auf einem Property verstößt nicht gegen “Information hiding”.
Ich bin ganz bei Dir, dass man darauf achten soll und muss. Aber Properties ändern nicht an diesem Problem.
Bei Properties kannst Du an der Deklaration die Sichtbarkeit des Members erkennt. Bei Getter/Settern eben nicht.
edit Beispiel:
public class WhatEverIAm {
private oneMember { private set; public get; }
}
Das ist schon lesbar, oder? Vorteil: Ich habe so nicht einmal die Möglichkeit, den Setter über diese Art zu überschreiben. Sprich, ich würde erwarten, dass bei Nutzung eines Setters mehr passiert, als nur den Member anzupassen.
Kenne das und habe das auch schon öfters gesehen aber mir erschloss sich nie der tiefere Sinn, dahinter.
Wenn ich getter und setter will dann klicke ich in Eclipse auf „Generate Getter/Setter“
Das einzige was mir daran fehlt ist das man in Eclipse Code nicht (automatisch) ausblenden kann.
Diese +/- Button an der Seite jeder Methode klappen sich ständig wieder auf 
und das bei jeder Änderung und immer und immer wieder…
[QUOTE=Timothy_Truckle;119915]Nur weil sie nicht so heißen bedeutet das nicht, dass es keine sind…
Für mich wäre so ein Feature nur dann sinnvoll, wenn ich eine Klasse explizit als DTO kennzeichnen könnte und dann einen Compilefehler erhielte, wenn mehr als hashcode() equals() und toString() implementiert würde.
bye
TT[/QUOTE]
Also wie Case-Classes in Scala?
[quote=TMII]Das einzige was mir daran fehlt ist das man in Eclipse Code nicht (automatisch) ausblenden kann.[/quote]Preferences->Java->Editor->Folding
bye
TT
[QUOTE=TMII]Kenne das und habe das auch schon öfters gesehen aber mir erschloss sich nie der tiefere Sinn, dahinter.
Wenn ich getter und setter will dann klicke ich in Eclipse auf „Generate Getter/Setter“
Das einzige was mir daran fehlt ist das man in Eclipse Code nicht (automatisch) ausblenden kann.
Diese +/- Button an der Seite jeder Methode klappen sich ständig wieder auf :/[/QUOTE]
Der tiefere Sinn liegt doch eigentlich auf der Hand. 
Du öffnest eine Klasse und kannst an den Memberdeklarationen direkt ablesen, wie die Sichtbarkeit ist. Es ist kein zusätzliches Generieren von Code notwendig. Und wenn es eine Klasse mit dediziertem Setter gibt, kann man sich direkt fragen: „Warum ist das so? Und wird da mehr gemacht, als nur einen Wert zu setzen?“.
Die meisten member Variablen sollten eh versteckt sein.
Das von Bleiglanz angesprochene ständig wiederholende generieren von gettern und settern ist eben jenes, was zu Problemen mit der Wartbarkeit führen kann.
Die meisten Getter und Setter brechen die Kapselung auf, da sie den inneren Zustand eines Objektes nach aussen geben.
Oftmals sind write-once also mit final Deklarierte Variablen die bessere Option.
Getter und Setter führen oft dazu, dass ein Programm lediglich aus dem Aufruf von Gettern und Settern besteht. Business-Methoden sind hier oft die bessere Alternative, weil sehr oft mehrere Werte simultan gesetzt werden müssen, bevor eine Prüfung der Konsistenz stattfinden kann.
Früher galt noch, dass die meisten Frameworks Getter und Setter brauchten. Heute können die meisten Frameworks auf Feldern arbeiten.
Einfach mal ein Coverage-Tool mitlaufen lassen und schauen ob und wie oft die Getter und Setter überhaupt aufgerufen werden.
[QUOTE=Timothy_Truckle;119928]Preferences->Java->Editor->Folding
bye
TT[/QUOTE]
Oder man geht einen anderen Weg und bindet z.B. Lombok ein. https://projectlombok.org/
Dass die Tatsache, dass diese “praktische Funktion, die von der IDE bereitgestellt wird”, dazu führt, dass Leute öfter mal willkürlich-unüberlegt Fields in eine Klasse klatschen, und dann pauschal “Generate getters and setters” anklicken (und vielleicht glauben, damit etwas richtig zu machen), es mir kalt den Rücken runterlaufen läßt, hatte ich schon an anderen Stellen erwähnt. Sicher können getter und setter zu einem gewissen “Code Bloat” führen (vor allem, wenn man sie JavaDoc’t). Der “Verstoß” gegen das https://en.wikipedia.org/wiki/Uniform_access_principle mag auch kritisiert werden. Aber ich finde es vertretbar. Das Verhältnis zwischen dem Aufwand (bzw. der Tragweite) einer Änderung, die private x { private set; public get; } erlauben würde, und ihrem unmittelbaren Nutzen, erscheint mir gering im Vergleich zu anderen Dingen. (Die Tragweite auch im Zusammenhang mit anderen Dingen, wie etwa Value Types (Value Types for Java))
Ob Getter/Setter immer gut sind, hat eigentlich wenig damit zu tun, dass es keine Properties in Java gibt. Ich teile dort zwar die Meinung in Bezug auf Information Hiding, trotzdem sind Properties einfach schön. Ich mag es, wenn die Sichtbarkeit an der Stelle geregelt wird, wo man auch etwas definiert. Das nimmt einem die IDE nicht ab - es sei denn, Getter und Setter folgen direkt der Deklaration, was ich persönlich total unschön finde.
Das ist ein Argument. Wenn man ein Field liest, weiß man erstmal nicht, ob irgendwo vielleicht ein setter/getter dafür existiert.
Das sehe ich auch so. Ich habe nur an dummen Datenklassen Getter (und Setter nur, wenn es absolut unmöglich ist, die Daten bei Initialisierung schon alle anzugeben). Sonst gibt es höchstens in Ausnahmefällen mal Getter.
In der Regel ist es viel besser, einer Klasse Aufträge zu geben, statt deren private Daten anderswo irgendwie zu verarbeiten und zurückzuschreiben.
Manchmal gehe ich daher so weit, dass ich nach einer Verarbeitung ein Objekt einer neuen Klasse erzeuge. Hat auch den Vorteil, dass dann alles schön final sein kann und ich mir schlicht sicher bin, dass die Daten nicht doch irgendwo ganz tief in Schicht Y manipuliert werden.