Getter/Setter - wie sieht ein Setter aus? Und wie nicht?

texs89

Mitglied
Getter/Setter
Ich habe eine Frage zu Settern. Sehen Setter immer exakt gleich aus, also setzen einfach nur das Attribut oder können diese auch eine Bedingung enthalten und sind dann immernoch Setter?

Z.B. das Attribut
Java:
Z.B. das Attribut private int preis;

Der Setter sieht so aus:

Code:
public void setPreis(int preis) {

this.preis = preis;

}

Wäre das auch ein Setter?
Code:
public void setPreis(int preis) {

if (preis >= 0) {

this.preis = preis;

}

}

Und was ist hiermit:

Code:
public void erhoehePreis(int pErhoehung) {

if (pErhoehung >0) {

this.preis = this.preis + pErhoehung;

} else {

System.out.println("Die Änderung ist nicht zulässig");

}

}

Ist das auch ein Setter? Weil das Attribut wird damit ja auch neu gesetzt? Ist also jede Methode, die das Attribut verändert, ein Setter?

Oder sind nur die ersten beiden per Definition Setter?
Vielen Dank!
 

ZwennL

Neues Mitglied
Es sind alles Setter und alle drei setzen das Attribut auch neu. Auch die Neuberechnung in Deinem letzten Beispiel verändert ja den Wert des Attributes preis. Allerdings hangt die Wahl, wie Du einen Setter implementierst davon ab, wie flexiebel Du ihn halten willst/ musst. Das bedeutet, der erste Setter ist am flexiebelsten, denn er setzt einfach den Preis neu mit dem übergebenen Parameter.

Die anderen beiden sind (gleich) unflexiebel, denn das Setzen des neuen Preises hängt von Bedingungen ab. Im Hinblick auf die Wiederverwendbarkeit von Code würde ich die erste Variante nehmen und die Abhängigkeitslogik vor den Aufruf des Setters auslagern. Du kannst den Aufruf des Setters davon abhängig machen, ob der bestehende Preis, den Du mit dem Getter abfragen kannst, die gewünschte(n) Bedingung(en) erfüllt. Eine der beiden anderen Versionen würde ich nur befürworten, wenn es für die Einschränkungen im praktischen Einsatz fundierte Gründe gibt.
 

M.L.

Top Contributor
Getter-/Setter-Methoden sind gewöhnliche Methoden, aber mit einer Namensgebung, die einen Rückschluss auf die implementierte Funktionalität zulässt ("Clean Code"). Z.B. könnte man in einer Getter-/Setter-Methode weitere Funktionalität implementieren:
Java:
public void setPreis(int preis) {

this.preis = preis;
System.out.println("Hallo, Preis wird gesetzt.");
}
 

Robert Zenz

Top Contributor
Es sind alles Setter. Sind es gute Setter? Nein.

Der klassiker ist:

Java:
public void setProperty(int property) {
    this.property = property;
}

Soweit so gut. Wenn du jetzt aber folgendes hast:

Java:
public void setProperty(int property) {
    if (property >= 0) {
        this.property = property;
    }
}

Hast du ein von Aussen nicht unmittelbar definierbares Verhalten. Und zwar:

Java:
item.setProperty(5); // Funktioniert
item.setProperty(9); // Funktioniert
item.setProperty(0); // Funktioniert
item.setProperty(Integer.MAX_VALUE); // Funktioniert

item.setProperty(-4); // Tut nichts

So, das Problem hier ist dass der Aufruf weder beim kompilieren noch zur Laufzeit einen Fehler produziert, aber keine Auswirkungen hat. Das kann viele lustige Stunden suchen bedeuten wenn man dahinein laeuft. Da ist dein naechstes Beispiel schon besser:


Java:
public void setProperty(int property) {
    if (property >= 0) {
        this.property = property;
    } else {
        System.out.println("Die Änderung ist nicht zulässig");
    }
}

Damit hat man zumindest zur Laufzeit die Chance zu bemerken das etwas nicht so funktioniert wie man das gerne haette. Aber es ist dennoch immer noch nicht gut. stdout kann sonst wohin zeigen und die Meldung verschwindet vielleicht auf nimmerwiedersehen.

Jetzt gibt es zwei Moeglichkeiten, du machst es definitiv und unmissverstaendlich klar wie sich die Methode verhaelt:

Java:
public void setPropertyIfValuePositiveOrZero(int property) {
    if (property >= 0) {
        this.property = property;
    }
}

Oder, was man in diesen Faellen macht ist eine IllegalArgumentException zu werfen wenn der Wert nicht zulaessig ist. Das sieht im einfachsten Fall so aus:

Java:
public void setProperty(int property) {
    if (property < 0) {
        throw new IllegalArgumentException();
    }
    
    this.property = property;
}

Damit merkst du zurt laufzeit ganz sicher dass es da ein problem gibt. Jetzt waere es natuerlich noch viel, viel besser wenn man auch weisz worum es geht:


Java:
public void setProperty(int property) {
    if (property < 0) {
        throw new IllegalArgumentException(String.format("The value of \"property\" must be zero or positive, but was <%d>.",
                Integer.valueof(property)));
    }
    
    this.property = property;
}

Denn damit bekommst du zur Laufzeit nicht nur die Stapelspur zu sehen, also wo der Fehler passiert ist, sondern auch was und warum:

Code:
IllegalArgumentException: The value of "property" must be zero or positive, but was <-4>.

Zusaetzlich, als Nachsatz, gibt es noch Fluent-Setter:

Java:
public Item setProperty(int property) {
    this.property = property;
    
    return this;
}

Damit kann man die Aufrufe hintereinander verketten:

Java:
Item item = new Item()
        .setProperty(5)
        .setOther("stuff")
        .setLast(thingything);

Das ist teilweise sehr interessant weil man dann "inline" Objekte aufsetzen kann ohne das man sich eine Variable dafuer anlegen muss. Ein gutes Beispiel ist da zum Beispiel das ausfuehren von Kommandos:

Java:
// Klassisch
Command command = new Command("command");
command.setFirstParameter("a");
command.setFirstParameter("b");
command.setFirstParameter("c");

executor.executor(command);

// Fluent
executor.executor(new Command("command")
        .setFirstParameter("a")
        .setFirstParameter("b")
        .setFirstParameter("c"));

Man muss sich also etwas weniger wiederholen in diesen Faellen.
 

KonradN

Super-Moderator
Mitarbeiter
Ich möchte dann doch noch ein paar Worte zu Fluent Interfaces schreiben. Denn das sieht ja erst einmal so toll aus ...

Das mit den fluent Settern ist etwas, das auch problematisch ist. Daher findet man diese auch meist nur in ganz speziellen Bereichen - das Builder Pattern wäre da ein super Beispiel. Die Idee ist dabei, dass Du nicht zig Konstruktoren hast oder du nicht ständig alle Dinge angeben musst. Sondern statt dessen erstellt man sich den Builder um da dann zu setzen, was nicht auf default Werten sein soll und dann bekommt man mit dem build() Aufruf die Instanz.

Bei dem Beispiel mit dem Command wäre dass dann ein Code wie:

Java:
executor.execute(Command.builder()
                 .setCommand("command")
                 .addParameter("a")
                 .addParameter("b")
                 .addParameter("c")
                 .build());

(@Robert Zenz Ich vermute, bei dem Code von Dir hast Du auch nicht 3 mal setFirstParameter aufrufen wollen, oder?)

Aber der Vorteil wäre, dass sowas bei fluent Settern auch jederzeit im laufenden Code geht. Daher ist dann die Frage: Wieso macht man das nicht generell so? Also nicht nur bezüglich Setter sondern generell? Fluent Interfaces sehen doch auf den ersten Blick so toll aus!

Da findet man dann z.B.:
Das ist nicht Java spezifisch, aber die genannten Problematiken treffen halt durchaus generell zu.

Das nur als wichtiger Hinweis, nicht dass man dann ab morgen meint, alles fluent machen zu wollen.

Ist aber auch natürlich nur meine Sichtweise. Kann sein, dass man sich da generell eine Vorgehensweise bauen kann, die halt die Probleme umgehen (z.B. durch bestimmte Vorgaben, wie da dann Dinge zu entwickeln sind) und die ggf. auf andere Dinge verzichten. Eine solche Vorgehensweise kenne ich so aber nicht und daher ist es durchaus problematisch in meinen Augen.
 

Robert Zenz

Top Contributor
(@Robert Zenz Ich vermute, bei dem Code von Dir hast Du auch nicht 3 mal setFirstParameter aufrufen wollen, oder?)

Wie kannst du es wagen meinen Code anzuzweifeln! ... Ich wollte eben setFirst, setSecond und so machen damit ich eben genau nicht addParameter oder withParameter habe und es als Setter-Beispiel verkaufen kann....das habe ich davon dass ich meine Beitraege nicht nochmal Korrektur lese...

Ich habe da auch absichtlich auf Builder verzichtet, weil ich nicht die Notwendigkeit sah.

Da findet man dann z.B.:
Das ist nicht Java spezifisch, aber die genannten Problematiken treffen halt durchaus generell zu.

Mh...muesste ich nochmal genauer lesen. Ist es schlimm dass mich das PHP stoert? Ich meine, ich weisz schon, generelle Beispiele, aber PHP und OOP ist jetzt nicht so...es ist halt PHP, okay? Und ich kann mich beim folgenden auch irren, also gerne werde ich korrigiert.

"Fluent Interfaces break Encapsulation", das Beispiel bricht aber den API-Vertrag, weil er retourniert nicht mehr "diese Instanz" sondern "eine andere Instanz" in der Methode. Man beachte dass in der Doku von der Schnittstelle ja auch "return self" steht, das bricht er halt einfach damit. Da kann man jetzt der Methodik nicht wirklich einen Vorwurf machen, weil wenn ich eine Methode habe getPrice und ich retourniere darin den Steuersatz, ist das halt einfach falsch. Ich verstehe was er meint, aber ich bin mir nicht sicher ob man dieses Problem wirklich hat in der echten Welt ohne den API-Vertrag der Schnittstelle zu verfeuern (und dann ist man eh raus).

"Fluent Interfaces break Decorators (and Composition)", das Beispiel ist auch wieder schlecht, weil eine Klasse zu wrappen ohne etwas ueber die Klasse zu wissen ist...schwierig. Kannst du machen, aber dann laeufst du genau in diese Sachen hinein.

"Fluent Interfaces are harder to Mock", das stimmt. Voll Arsch wenn man das machen muss, tippt sich wie ein Bauklotz.

"Fluent Interfaces make diffs harder to read", ... wat?! Echt jetzt? Mit der Argumentation muesste ich jede Zeile mit einem Kommentar mit der aktuellen Klasse, Methode, und Sub-Block beginnen um das Problem etwas abzuschwaechen.

"Fluent Interfaces are less readable", das ist ein schoenes Beispiel. Aber faellt halt unter API-Design, man muss die API schon entsprechend entwerfen, und da helfen Fluent Sachen eventuell nicht, oder schon. Und der verwendende Entwickler muss auch ein biszchen Verantwortung einbringen.

"Fluent Interfaces cause BC breaks", der Absatz ist nicht ernst gemeint, oder?

Das nur als wichtiger Hinweis, nicht dass man dann ab morgen meint, alles fluent machen zu wollen.

Das ist ein guter Rat, der auch allgemein Gueltigkeit hat. "Methodik X ist kein Universalheilmittel fuer alles." Punkt. Da bin ich dabei.
 
Zuletzt bearbeitet:

Robert Zenz

Top Contributor
Aber wenn wir schon bei den negativen Seiten von Fluent-Dingen sind, dann muss man hier definitiv Spring Boot Security nennen. Dieses HTTP-Authorization-Teil bereitet mir jedes mal schlaflose Naechte wenn ich etwas daran aendern muss. Das ist ein sehr schoenes Negativ-Beispiel (und ueberhaupt jede Stelle in Spring wo sie versucht haben mit Fluent-Methoden eine eigene DSL abzubilden).

Also, kann definitiv negativ sein, ja.
 

KonradN

Super-Moderator
Mitarbeiter
Ist es schlimm dass mich das PHP stoert?
Ich denke, dass ist vollkommen normal und dein Ansehen in meinen Augen würde enorm leiden, wenn es nicht so wäre :)

"Fluent Interfaces break Encapsulation", das Beispiel bricht aber den API-Vertrag, weil er retourniert nicht mehr "diese Instanz" sondern "eine andere Instanz" in der Methode.
Ja, vollkommen klar. Das ist in der Ausführung so nicht ganz korrekt.

Das Problem ist aber aus meiner Sich hier schlicht, dass es unübersichtlich wird. Wenn Du nun eine Klasse MyCoolClass hast und die Methode
doSomething(), die ein MyCoolClass zurück gibt:
  • Ist das nun fluent?
  • Oder ist es eine Klasse, die immutable ist?
(Ja, ich bin ein "final" Fetischist ... bei mir wird so viel final :) )

Und dann kommen eben Fehler. Entweder weil man eben den API Vertrag bricht oder man bei der Nutzung etwas übersehen hat. Klar ein Fehler des Entwicklers. Aber das ist ein Fehler, den man erst einmal sehen muss. Wenn ich ein Builder Pattern habe, dann erwarte ich dieses Verhalten. Habe ich kein Builder, der erwarte ich das Verhalten nicht. Wenn also String, BigDecimal oder sonst eine Klasse eine Instanz mit gleichem Typ zurück gibt, dann erwarte ich nicht die gleiche Instanz. Das ist so meine Sicht und ich würde da bei einem Review drüber stolpern, wenn da etwas wäre wie:
Java:
Car car = new Car();
// ...
car.setSpeed(50)
    .setDirection(310)
    .openWindow(Car.BACK_RIGHT, 50)
    .openWindow(Car.FRONT_LEFT, 0);

Aber das ist meine persönliche Sichtweise. Das mögen andere anders sehen und wenn man versucht, alles fluent zu machen, dann ist das vielleicht schöner. Das gestehe ich durchaus ein bei diesem Punkt.

"Fluent Interfaces break Decorators (and Composition)", das Beispiel ist auch wieder schlecht, weil eine Klasse zu wrappen ohne etwas ueber die Klasse zu wissen ist...schwierig. Kannst du machen, aber dann laeufst du genau in diese Sachen hinein.
Ja, das Problem ist, dass man da deutlich mehr wissen muss und eben gewisse Dinge nicht gehen. Nur manchmal erwartet man eben, dass gewisse Dinge gehen, weil z.B. ein Framework daherkommen könnte um etwas zu wrappen. Man wirft somit einige AOP Möglichkeiten weg. Das kann man machen, aber dann sollte man einen guten Grund haben. Ohne guten Grund würde ich mich nicht einschränken wollen.
Man mag zwar denken: "AOP? Mache ich doch eh nicht" aber teilweise ist es plötzlich Bestandteil irgendwelcher Frameworks ... Dann steckt es irgendwo drin, wo man es evtl. gar nicht will.

"Fluent Interfaces cause BC breaks", der Absatz ist nicht ernst gemeint, oder?
Das ist ein Punkt, der nur in PHP gilt. Da frickelt die Leute halt nur ... Damit ist das PHP bashing eröffnet :)

(So weit hatte ich übrigens erst gar nicht gelesen beim überfliegen. Mir ging es mehr um die groben Punkte. Die Begründungen mögen im Detail nicht ganz stimmig sein und es mag bestimmt Besseres zu finden sein zu diesem Thema. Ich habe halt nur ganz kurz gesucht und den ersten Treffer nicht zu genau untersucht, als ich den Link gebracht habe. Da habe ich also schlicht ungenau gearbeitet.)

Bezüglich der nicht zitierten Dinge: Da bin ich ganz bei Dir!

Aber wenn wir schon bei den negativen Seiten von Fluent-Dingen sind, dann muss man hier definitiv Spring Boot Security nennen. Dieses HTTP-Authorization-Teil bereitet mir jedes mal schlaflose Naechte wenn ich etwas daran aendern muss. Das ist ein sehr schoenes Negativ-Beispiel (und ueberhaupt jede Stelle in Spring wo sie versucht haben mit Fluent-Methoden eine eigene DSL abzubilden).
Wobei das ja für mich unter Builder Pattern fällt - da baut man ja die Configuration mit auf. Das wäre also noch durchaus ok. (Aber ja, es ist ein Beispiel für schlechte Lesbarkeit!)
 

Robert Zenz

Top Contributor
Ich denke, dass ist vollkommen normal und dein Ansehen in meinen Augen würde enorm leiden, wenn es nicht so wäre :)

Gut. :)

(Ja, ich bin ein "final" Fetischist ... bei mir wird so viel final :) )

Solange du keine Bibliothek oder Framework schreibst, ist das in Ordnung. :) Wenn du eine Bibliothek oder Framework schreibst zur allgemeinen Verwendung dann...bitte nicht. Also mein primaerer Hassgrund dafuer ist JavaFX, weil die einfach final wie Sprinkel verwendet haben und wenn du etwas erweitern musst, du dann einfach ganze Klassen kopieren musst. Vaadin ist im uebrigen mein Hassgrund fuer package-private aus genau dem gleichen Grund.

Das Problem ist aber aus meiner Sich hier schlicht, dass es unübersichtlich wird. Wenn Du nun eine Klasse MyCoolClass hast und die Methode
doSomething(), die ein MyCoolClass zurück gibt:
  • Ist das nun fluent?
  • Oder ist es eine Klasse, die immutable ist?
(Ja, ich bin ein "final" Fetischist ... bei mir wird so viel final :) )

Und dann kommen eben Fehler. Entweder weil man eben den API Vertrag bricht oder man bei der Nutzung etwas übersehen hat. Klar ein Fehler des Entwicklers. Aber das ist ein Fehler, den man erst einmal sehen muss. Wenn ich ein Builder Pattern habe, dann erwarte ich dieses Verhalten. Habe ich kein Builder, der erwarte ich das Verhalten nicht. Wenn also String, BigDecimal oder sonst eine Klasse eine Instanz mit gleichem Typ zurück gibt, dann erwarte ich nicht die gleiche Instanz. Das ist so meine Sicht und ich würde da bei einem Review drüber stolpern, wenn da etwas wäre wie:
Java:
Code:
Car car = new Car();
// ...
car.setSpeed(50)
    .setDirection(310)
    .openWindow(Car.BACK_RIGHT, 50)
    .openWindow(Car.FRONT_LEFT, 0);

Aber das ist meine persönliche Sichtweise. Das mögen andere anders sehen und wenn man versucht, alles fluent zu machen, dann ist das vielleicht schöner. Das gestehe ich durchaus ein bei diesem Punkt.

Ja, das ist ein viel besseres und sehr gutes Beispiel. Dagegen kann ich mich nicht wehren. Dann muss man in dem Fall ueber Dokumentation der entsprechenden Klassen und Methoden gehen um dies klar zu definieren.

Ja, das Problem ist, dass man da deutlich mehr wissen muss und eben gewisse Dinge nicht gehen. Nur manchmal erwartet man eben, dass gewisse Dinge gehen, weil z.B. ein Framework daherkommen könnte um etwas zu wrappen. Man wirft somit einige AOP Möglichkeiten weg. Das kann man machen, aber dann sollte man einen guten Grund haben. Ohne guten Grund würde ich mich nicht einschränken wollen.
Man mag zwar denken: "AOP? Mache ich doch eh nicht" aber teilweise ist es plötzlich Bestandteil irgendwelcher Frameworks ... Dann steckt es irgendwo drin, wo man es evtl. gar nicht will.

Ja, muesste ich nochmal darueber nachdenken.

Das ist ein Punkt, der nur in PHP gilt. Da frickelt die Leute halt nur ... Damit ist das PHP bashing eröffnet :)

Yeah!

Bezüglich der nicht zitierten Dinge: Da bin ich ganz bei Dir!

Ich auch bei dir.

Wobei das ja für mich unter Builder Pattern fällt - da baut man ja die Configuration mit auf. Das wäre also noch durchaus ok. (Aber ja, es ist ein Beispiel für schlechte Lesbarkeit!)

Nein, nein, nein, das Teil ist nicht okay! Weder als Builder noch als Fluent! Du wechselst naemlich konstant das Objekt und hast dann dementsprechend andere Methoden zur Verfuegung, und hier und da finalisiert der Wechsel auch das vorherige Objekt und du bekommst dann zur Laufzeit einen Fehler...nein, nein, nein, das Ding ist einfach nicht okay!
 

KonradN

Super-Moderator
Mitarbeiter
Solange du keine Bibliothek oder Framework schreibst, ist das in Ordnung. :) Wenn du eine Bibliothek oder Framework schreibst zur allgemeinen Verwendung dann...bitte nicht. Also mein primaerer Hassgrund dafuer ist JavaFX, weil die einfach final wie Sprinkel verwendet haben und wenn du etwas erweitern musst, du dann einfach ganze Klassen kopieren musst. Vaadin ist im uebrigen mein Hassgrund fuer package-private aus genau dem gleichen Grund.
Das wäre kein Problem. Ich mache nicht die Klassen oder Methoden final (Kann auch mal vorkommen, aber das kommt selten vor. Methoden z.B., wenn diese vom Konstruktor aufgerufen werden). Aber sehr wohl sehr viele Variablen und alle Parameter (Das sind ja Eingangswerte - da wird nichts zugewiesen!).

Da folge ich relativ konsequent PMD - das verhaut mich, wenn ich es nicht mache. Also so typischer Fall, dass man eine lokale Variable nutzt um eine neue Instanz einer Kkasse zu erzeugen und damit macht man dann etwas. Ruft etwas darauf auf, übergibt es irgendwohin. Und das war es.
Und einfach ein Substring in einer lokalen Variable zu speichern um es dann an mehreren Stellen (ohne Zuweisung) weiter zu verwenden, ist dann bei mir ein final String subString = someCoolString.substring(start, end);

Nein, nein, nein, das Teil ist nicht okay! Weder als Builder noch als Fluent! Du wechselst naemlich konstant das Objekt und hast dann dementsprechend andere Methoden zur Verfuegung, und hier und da finalisiert der Wechsel auch das vorherige Objekt und du bekommst dann zur Laufzeit einen Fehler...nein, nein, nein, das Ding ist einfach nicht okay!
Ach so? Da sieht man, dass ich kein Spring Security Fachmann bin. Aber das ist dann natürlich Quatsch und tatsächlich so nicht ok.
 

Robert Zenz

Top Contributor
Das wäre kein Problem. Ich mache nicht die Klassen oder Methoden final (Kann auch mal vorkommen, aber das kommt selten vor. Methoden z.B., wenn diese vom Konstruktor aufgerufen werden). Aber sehr wohl sehr viele Variablen und alle Parameter (Das sind ja Eingangswerte - da wird nichts zugewiesen!).

Ja, das ist gut.

Ach so? Da sieht man, dass ich kein Spring Security Fachmann bin. Aber das ist dann natürlich Quatsch und tatsächlich so nicht ok.

Hier ist ein offizielles Beispiel:

Java:
	@Bean
	public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
		http
			.authorizeHttpRequests((requests) -> requests
				.requestMatchers("/", "/home").permitAll()
				.anyRequest().authenticated()
			)
			.formLogin((form) -> form
				.loginPage("/login")
				.permitAll()
			)
			.logout((logout) -> logout.permitAll());

		return http.build();
	}

Ich wuenschte ich koennte dir zeigen was in meinem Arbeitsprojekt da abgeht...aber irgendwie darf ich das nicht. Und auf der anderen Seite, das offizielle Beispiel ist, glaube ich, mehr als genug um zu zeigen wie das eskaliert (und moegen dir die Maechte helfen wenn du zwei unterschiedliche Pfade hast die unterschiedliche Konfigurationen brauchen).

Obwohl, das hier ist auch sehr schoen um meinen Punkt zu zeigen. Und immer im Kopf behalten, dass ist nicht immer das HttpSecurity Objekt welches retourniert wird.
 

KonradN

Super-Moderator
Mitarbeiter
Ja, wenn man sich HttpSecurity anschaut, dann sieht man es ja auch sofort:

Man muss nur die Methoden durchgehen und schauen, was die zurück geben ... teilweise HttpSecurity (fluent Ansatz) und sehr viel unterschiedliche XyzConfigurer<HttpSecurity> - also ganz klar sehr viel gemixt.
 

Robert Zenz

Top Contributor
@texs89 Also mitschreiben, so macht man es nicht.

Ueberhaupt in 99% der Faelle wenn du dir denkst "Ich kann hier eine DSL (Domain Specific Language) machen" gilt dann einfach "Mach' es nicht!". Und fuer den Rest mach' sie nicht als Objektstruktur sondern als richtige Sprache.
 

White_Fox

Top Contributor
Solange du keine Bibliothek oder Framework schreibst, ist das in Ordnung. :) Wenn du eine Bibliothek oder Framework schreibst zur allgemeinen Verwendung dann...bitte nicht. Also mein primaerer Hassgrund dafuer ist JavaFX, weil die einfach final wie Sprinkel verwendet haben und wenn du etwas erweitern musst, du dann einfach ganze Klassen kopieren musst. Vaadin ist im uebrigen mein Hassgrund fuer package-private aus genau dem gleichen Grund.
Da kannst du doch aber nicht auf das arme final eindreschen, das kann nix dafür daß die JavaFX-Frickler einen Riesenhaufen Scheiße gebaut haben. Ich sach nur TableView, wie kann man nur auf so eine bekloppte Idee kommen und die Spaltenbeschriftung GUI-seitig aus dem Quellcode rausklauben...
 

Robert Zenz

Top Contributor
Da kannst du doch aber nicht auf das arme final eindreschen, das kann nix dafür daß die JavaFX-Frickler einen Riesenhaufen Scheiße gebaut haben. Ich sach nur TableView, wie kann man nur auf so eine bekloppte Idee kommen und die Spaltenbeschriftung GUI-seitig aus dem Quellcode rausklauben...

Ich konnte mich gar nicht mehr erinnern wie das funktioniert hat, ich habe damals die Spalten haendisch erzeugt und konnte daher den Text selbst setzen, aber ich sehe da gerade nicht mehr wie die Uebersetzung von dem funktioniert hat. Ich glaube das habe ich vergessen zu implementieren.

Aber irgendwo dort fliegt noch eine selbstgestrickte ComboBox herum, weil eine bestimmte Methode final war in der von JavaFX...
 

Neumi5694

Top Contributor
@texs89
Grundsätzlich darf ein Setter die Eingabe verändern oder ablehnen.
Einen Preis auf < 0 zu setzen, ist klarerweise nicht sinnvoll. Aber ist es sinnvoll, ihn dann gar nicht zu setzen? Oder gibt es eine bessere Möglichkeit?
Du musst dir gut überlegen, was dann passieren soll. Wie auch immer die Entscheidung ausfällt, es gibt hier 3 sehr wichtige Regeln:
Regel #1: Dokumentieren
Regel #2: Dokumentieren
Regel #3: Dokumentieren

Wir haben Java-Doc für die API-Dokumentation. Schreib in die Dokumentation rein, was mit den Werten passiert.
Wann wird er korrigiert?
Wann wird er abgelehnt?
Wann gibt's eine Exception?
Die Dokumentation darf dabei ruhig auch 3 mal so lang sein wie der Code in der Methode, das ist überhaupt kein Problem.

Du kannst natürlich noch eine Rückgabe liefern, die beschreibt, ob mit dem Wert was passiert ist und/oder was, hier gilt Regel #4: Dokumentieren
 

White_Fox

Top Contributor
Ich konnte mich gar nicht mehr erinnern wie das funktioniert hat
So ganz genau weiß ich das auch nicht mehr. Auf jeden Fall mußtest du der TableView die "Datensatzklasse" bekanntmachen, die die Daten enthält die angezeigt werden sollten.
Dann hat der z.B. von der Klasse "Person" die Methode "getName" genommen, eine Spalte "Name" gebildet und dort von jedem Person-Objekt, daß du dem RiesenShitHaufen hingeworfen hast, eingetragen was auch immer er von der Methode "getName" bekommt.

Und wenn du die Methode umbenannt hast in getStupidShit umgeändert hast, stand dann StupidShit im Spaltenkopf.
Ich habe ein Weilchen über dem Tutorial und dem Beispielcode gerätselt, wie der Beispielcode funktionieren soll, bis ich das einfach mal geändert habe, die Idee erschien mir einfach zu blöd als daß sie jemand so umsetzen würde. Vorher jedenfalls.

Und "Stupid Shit", mit Leerzeichen in der Mitte...keine Ahnung, vielleicht wenn man die Methode in getStupid_Shit ändert, ausprobiert habe ich es nicht, ich war danach damit beschäftigt die Hutschnur wieder zusammenzubinden.
Viel Spaß wenn man stattdessen "dämlichen Blödsinn" drinstehen haben will, oder gar "глупая чепуха", vielleicht sogar abhängig von der gesetzten Lokalvariable...heieiei...
 

Robert Zenz

Top Contributor
Daran kann ich mich jetzt aber wieder erinnern dass deren Standard ist dass man ein Model hineinschiebt und die Spaltentitel anhand der Methoden geraten werden, ja. Das ist eine Idee.

Ich glaube man muss dann die Spalten haendisch anlegen oder damit man eigene Texte setzen kann. Ich kann mich nicht mehr erinnern was ich alles probiert hatte bis ich dann zu der Loesung gekommen bin. Wahrscheinlich einiges.
 

AndiE

Top Contributor
Ich habe mal gelernt, auf "Getter" und "Setter" als Bezeichnung zu verzichten. Es könnte von "MrBrown" stammen.

Das hat die Bewandnis, dass man viele Daten, die unveränderlich sind, schon dem Konstruktor mitgeben kann. Statt "getPrice" wäre ein "ShowPrice" besser, weil man da dichter an der umzusetzenden Use-Story ist. Statt einem "setPrice" wäre dann auch ein "updatePrice" sinnvoller. Denn ein Pris ist ja schon da, man verändert ihn nur. Je nach Vorgabe würde man sogar eine "PriceHistory" anlegen.
 

Robert Zenz

Top Contributor
Statt "getPrice" wäre ein "ShowPrice" besser, weil man da dichter an der umzusetzenden Use-Story ist.

"Show" stimmt in dem Zusammenhang eben nicht ganz, weil du zeigst den preis ja nicht an, du holste ihn.

Java:
BigDecimal totalPrice = item.showPrice().multiply(new BigDecimal(4));

Sieht halt einfach falsch aus.

Statt einem "setPrice" wäre dann auch ein "updatePrice" sinnvoller.

Da bin ich schon eher dabei, aber update impliziert eine Aktion, so ein biszchen. "set" ist klar, das setzt, "update" setzt auch, aber klingt ein wenig so als wuerde es noch etwas machen (koennen).
 

White_Fox

Top Contributor
Mit der Argumentation wäre die Bezeichnung get/set ja komplett überflüssig, wobei ich bei Update auch noch etwas mehr Bewegung erwarten würde, z.B. eine Benachrichtigung an Objekte, für die der neue Preis wichtig ist.

Bei get/set hat es sich aber so eingebürgert, daß einfach nur eine Variable geändert wird. Alleine deshalb würde ich mir gut überlegen, ob man davon abweichen will.

Man kann sich natürlich für alles irgendwas Neues ausdenken, siehe Master-Slave-Annotation, wahrscheinlich verbessert man damit aber nix sondern holt sich auf seinen Partikularinteressen einen runter.
 

Robert Zenz

Top Contributor
Mit der Argumentation wäre die Bezeichnung get/set ja komplett überflüssig, wobei ich bei Update auch noch etwas mehr Bewegung erwarten würde, z.B. eine Benachrichtigung an Objekte, für die der neue Preis wichtig ist.

Das gibt es doch auch:

Java:
public interface Item {
    public BigDecimal price();
    public void price(BigDecimal price);
}
 

White_Fox

Top Contributor
Naja, das würde ich – ich habe ja von der Programmiererei keine Ahnung ;) – eher als Eigenschaft auffassen, du hast dann kein Verb im Text. Bis auf die Methodenklammern am Ende hat das dann den Charakter, als würde man direkt auf die Feldvariable zugreifen.

Ich finde daß es sich zumindest nicht schlecht liest, wobei das den inneren Monk bei mir etwas antriggert, Methoden implizieren ja eine Aktivität und es hat einen gewissen Stil sowas mit einem Verb beginnen zu lassen.

Beides ist aber nicht mit einer Methode updatePrice() zu vergleichen, finde ich jedenfalls.
 

Neumi5694

Top Contributor
Wenn ohne Kontrolle einfach nur eine Variable geändert wird und nichts anderes, dann könnte man diese genausogut public machen und gut is.
Die Methoden sind eben dazu da, den Zugriff kontrollieren und einen gesetzten Wert gegebenenfalls korrigieren zu können.
 

thecain

Top Contributor
Zusätzlich ist das halt auch der JavaBean Standard und wird in gewissen Fällen so erwartet (dann aber auch eher "Standard" getter und setter)
 

KonradN

Super-Moderator
Mitarbeiter
Wenn ohne Kontrolle einfach nur eine Variable geändert wird und nichts anderes, dann könnte man diese genausogut public machen und gut is.
Die Methoden sind eben dazu da, den Zugriff kontrollieren und einen gesetzten Wert gegebenenfalls korrigieren zu können.
Der wichtige Punkt ist dabei aber die Kapselung! Wenn der Zugriff auf die Variable gegeben wird, dann wird ein Implementationsdetail nach außen gegeben das dann nicht mehr geändert werden kann (Ohne die Schnittstelle zu ändern).

Einfaches Beispiel:
Java:
public class User {
    // ...
    public String password;
    // ...
}

Damit wird ein Passwort gespeichert - Das ist dann nicht mehr veränderbar.

Habe ich aber einfach ein
Java:
public class User {
    // ...
    public void setPassword(String password);
    // ...
}
dann kann ich frei überlegen, was da passiert und was ich am Ende speichere. Dann speichere ich z.B. nicht das Passwort sondern nur einen Hash.

und wird in gewissen Fällen so erwartet
Und unabhängig von dem Standard: Die Erwartungshaltung ist wichtig. Was erwartet ein Entwickler? Und man sollte die Erwartungshaltung erfüllen. Warum ist ein Auto so aufgebaut, wie es aufgebaut ist (Jetzt von der Bedienung her)? Da kann man doch auch ganz tolle Ideen haben bezüglich moderner Bedienung. ==> Dann findet sich ein Autofahrer nicht zurecht. Es wird gemacht, was ein Autofahrer auch erwartet. So kann man sich in ein neues Auto setzen, ohne erst die Bedienanleitung zu lesen a.la. "Blinker get nun über das rechte bzw. linke Pedal ... ahh, gut!"

Wenn man also "Clean Code" schreiben will, dann gibt es gewisse Dinge zu beachten und daran hält man sich am Besten.

eher als Eigenschaft auffassen
Dieses "als Eigenschaft" auffassen sehe ich ähnlich. Aber Java hat dieses Sprachkonzept nicht! Das ist ein ganz einfaches Sprachkonzept, das es seit über 20 jahren gibt und das Java schlicht nicht will. Wäre so einfach:

Code:
public String myProperty {
    get: {
        // getMyProperty code
    },
    set: {
       // setMyProperty code
    }
}

Nutzbar wäre dies dann einfach als myInstance.myProperty - bei einem lvalue in einem Statement (Zuweisung) wäre es ein Setter und ansonsten halt als Expression der Getter. (und der get / set Teil sind natürlich optional. Es kann also nur ein get oder nur ein set geben!)

Man könnte auch sagen: Hey, wenn man da nur eine Variable setzen will, dann macht das System das Alleine, also statt:
Java:
private String _myProperty;
public String myProperty {
   get: {
       return _myProperty;
    },
    set: {
        _myProperty = value; // value wäre dann der vorgegebene Parameter
    }
}

Würde man dann erlauben:
Code:
public String myProperty { get, set };

Bei Fragen rund um "Was für tolle Ideen man zu Properties noch haben könnte" fragen sie MSDN oder Ihren bekannten C# Entwickler.

Daher bin ich hier durchaus der Meinung, dass eben dies in Java nicht gewollt ist und daher wäre ich damit auch sehr vorsichtig. Den Getter so zu verwenden: Ja, ok. Das ist durchaus lesbar und verständlich - da spricht nichts dagegen. Was "myCar.price()" macht, kann man verstehen. (Aber ist der Unterschied so groß zu myCar.getPrice()? Von der Lesbarkeit bevorzuge ich Letzteres!) Aber als Setter ist es in meinen Augen ein Unding: "myCar.price(100)" finde ich nicht gut. Aber ja: Sowas findet sich auch wobei ich dies in der Praxis bisher nur in Builder Pattern gesehen habe. (Aber auch da bevorzuge ich die Variante mit dem "set"! Aber das ist nur meine pers. Sicht.)
 

temi

Top Contributor
Ich bin beim Einsatz von Gettern und vor allem von Settern eher vorsichtig. Im Sinne einer guten Datenkapselung ist es schlicht Unsinn für jede Instanzvariable einfach mal einen Getter/Setter zu erstellen. Der Zustand einer Instanz sollte sich durch fachliche Methoden verändern und nicht durch stumpfes Setzen eines Wertes, z. B. auto.accelerate() anstatt von auto.setSpeed(100). Es gibt natürlich auch Ausnahmen.

Zudem muss der Typ des gesetzten Wertes nicht zwangsweise dem intern verwendeten Datentyp entsprechen. @KonradN hat ja ein Beispiel genannt. Ein Passwort wird vermutlich nicht als String im Klartext gespeichert werden, sondern als Hashwert.

Das gilt auch für das Holen eines Wertes. In einer Konto-Klasse könnte der Kontostand beispielsweise nicht als separate Instanzvariable, sondern als Liste von einzelnen Kontobewegungen gespeichert sein, aus welcher der genaue Wert errechnet wird.
 

Neumi5694

Top Contributor
Der wichtige Punkt ist dabei aber die Kapselung! Wenn der Zugriff auf die Variable gegeben wird, dann wird ein Implementationsdetail nach außen gegeben das dann nicht mehr geändert werden kann (Ohne die Schnittstelle zu ändern).
Genau darum geht's. Wozu kapseln, wenn man eh nur direkt setzt?
Nur wenn das Implementationsdetail aus mehr als einer direkten Zuweisung bestehen kann, ist das von Belang.

dann kann ich frei überlegen, was da passiert und was ich am Ende speichere. Dann speichere ich z.B. nicht das Passwort sondern nur einen Hash.
Das hast du hier ja auch schon angesprochen.

Ich will in keiner Weise sagen, dass Kapselung schlecht wäre.
Nur der Unsinn, dass ein Setter nichts anderes tun soll, als eine Variable ungeprüft zu setzen, das will mir nicht in den Sinn.


Auch zum Rest ... ich finde ein getXY oder isXY durchauis sinnvoll. Der Trend geht aber leider in eine etwas andere Richtung, wie wir in C# und neuerdings auch in den Java records sehen.
Klar werden in C# intern durchaus getter und setter verwendet, aber im Quellcode sieht man nur noch den Propertynamen

Code:
public String AProperty {
 get {
   //Wert liefern
 }
 set {
   //Variable prüfen, setzen, was auch immer. übergebener Parameter heißt immer "value"
 }
}

void myMethod() {
  var  a = myObject.AProperty;
  myObejct.AProperty = a;
}
Intern werden hier die Get und Set Methoden von Property aufgerufen. Finde ich ehrlich gesagt keine so tolle Entwicklung, positiv anzumerken ist halt, dass es so deutlich weniger Klammern gibt.
 
Zuletzt bearbeitet:

KonradN

Super-Moderator
Mitarbeiter
Genau darum geht's. Wozu kapseln, wenn man eh nur direkt setzt?
Nur weil Du JETZT nur etwas direkt setzt, heisst es nicht, dass es in Zukunft auch so ist. Das ist doch der Hintergedanke bei der ganzen Kapselung.

Nur der Unsinn, dass ein Setter nichts anderes tun soll, als eine Variable ungeprüft zu setzen, das will mir nicht in den Sinn.
a) Es sagt niemand, dass er nichts anderes tun soll oder darf.
b) Die Möglichkeiten sind natürlich etwas eingeschränkt, da durch den Namen halt vorgegeben wurde, was gemacht wird.

Aber es gibt übliche Dinge wie Logging oder ein Observer Pattern. Evtl. löst es auch gewisse Dinge aus, so dass eine Kettenreaktion erfolgt. Wobei ich dies trennen würde in eine andere Methode (Die aber dann natürlich dennoch angetriggert wird!).


Properties sind halt ein neues Konstrukt welches genau das abbildet, was da jemand hier im Thread vermisst hat: Eigenschaften, auf Englisch Properties.
(Und das sind keine get und set Methoden. Das sind die get / set Accessors. Wird ja auch deutlich, denn da gibt es weder Rückgabetyp noch Parameter wie sie ja bei einer Methode anzugeben wären.)

Und wenn Du da mal schaust: Unter dem Strich gibt es dem Entwickler die Möglichkeit, etwas zu bauen, das fast einer Instanzvariable gleich kommt. Du hast nur eben ein { get; set } dahinter (Oder du hast auch das Feld gebaut und dann ein => feld gesetzt).

Du nutzt es dann, wie eine Instanzvariable von außen.
Aber Du hast die Möglichkeit, diese Interfacebeschreibung jedezeit zu verändern. Aus dem
C#:
public string Password { get; set };

machst Du dann halt später problemlos
C#:
private string _passwordHash;

public string Password {
    get => throw new InvalidOperationException("Password cannot be retrieved!");
    set => _passwordHash = HashPassword(value);
}
machen.

Damit kannst Du die innere Implementierung jederzeit ändern, weil Du diese eben nicht nach außen gibst. Was ja auch - wie am Anfang schon erklärt - ja der Sinn der Kapselung ist.
 

White_Fox

Top Contributor
Nur weil Du JETZT nur etwas direkt setzt, heisst es nicht, dass es in Zukunft auch so ist.
Eben. Eine get-Methode macht den Code nicht unleserlich, es ist nur etwas Tipparbeit beim Schreiben der Klasse. Diese Tipparbeit halte ich aber für vernachlässigbar, da geht weitaus mehr Zeit und Hirnschmalz beim Benamsen der Feldvariable drauf, und diese Benamsung halte ich für weitaus wichtiger.

Und für diejenigen, denen das Tippen schwerfällt (aber die sind in der Programmiererei sowieso falsch, finde ich), gibt es heute Codegeneratoren jeglicher Art. Gib den Namen deiner Feldvariable ein, einen Haken bei 'create getter' und 'create setter' setzen, je nachdem was man will, und den Typen der Variablen angeben, und dann hat man den Code inklusive Javadoc fertig reingedrückt.
Und dank Autovervollständigung muß man auch nicht mehr ganze Methodennamen ausschreiben.
 

AndiE

Top Contributor
Ich finde, dass man im Sinne der Datenkapselung Getter und Setter möglichst sparsam einsetzen sollte. Nehmen wir z.B. eine "Money"-Klasse, die Geldbeträge speichert. Allgenein werden diese werte als 1/10-Cent gespeichert und dann als long abgelegt. Es ist also ziemlich unsinnig, den "long betrag" als "setBetrag(long geld)" zu deklarieren, weil der Nutzer diese werte natürlich als "float" eingibt "0.00". Auch "float getValue()" macht erst aus dem long eine Fließkommazahl. Veränderungen des Wertes würde ich auch nicht mit set vornehmen, sondernmit "addValue( float f)" und "subValue( float f)".Den Wert selbst würde ich im Konstruktor setzen. Auf eine Dekleration "setValue()" würde ich ganz verzichten.
 

White_Fox

Top Contributor
Es ist also ziemlich unsinnig, den "long betrag" als "setBetrag(long geld)" zu deklarieren, weil der Nutzer diese werte natürlich als "float" eingibt "0.00".
Das ist nur eine Frage der Formatierung, bzw. kann man es zu solch einer degradieren.
Bei so einem Konstrukt würde ich mir eher etwas basteln, daß den Wert tatsächlich als Long entgegennimmt und den Dezimaltrenner nur als graphischen Zucker einfügt (und natürlich mit zehn multipliziert). Denn: Wenn du den Wert als Zentelcent speicherst, was machst du dann wenn der Nutzer (warum auch immer) Werte außerhalb des zulässigen Bereichs eingibt (weil er sie eingeben kann)? Klar kann man einfach eine Fehlermeldung zurückgeben, aber ich bin ein Freund davon, den Benutzer Dinge einfach nicht tun lassen zu können, die er nicht tun sollte. Und einen Betrag einfach nur mit dem Numfeld einzugeben, ohne noch das Komma eintippen zu müssen, halte ich für recht charmant (genauso wie ich es bevorzuge, Uhrzeiten als vierstellige Zahl eingeben zu können ohne ':' dazwischen).

Auch "float getValue()" macht erst aus dem long eine Fließkommazahl.
Warum nicht beim Long bleiben, und das im Methodenvertrag entsprechend deklarieren? Ich denke, das ist doch der Grund dafür daß man das als Long speichert, eben um Fehldarstellung zu vermeiden. Dann würde ich strikt bei Long bleiben und float gar nicht erst anfassen, außer externe Schnittstellen oder dergleichen würden das erzwingen.

Veränderungen des Wertes würde ich auch nicht mit set vornehmen, sondernmit "addValue( float f)" und "subValue( float f)".
Naja...kommt darauf an. Wenn ich nur eine Veränderung zulassen will wie daß bei einem aktuellen Wert von 20 ein addValue(30) den Wert auf 50 setzt, dann ja. Wenn ein addValue(20) aber den Wert auf 20 setzen soll, finde ich setValue schon richtig.
 

KonradN

Super-Moderator
Mitarbeiter
Ich denke, die Ideen wiederholen sich recht stark. Die Gedankengänge sind alle auch durchaus valide und man muss halt immer schauen, was die Anforderungen sind, die man bedienen muss.

Eine Idee, die bisher noch nicht gekommen ist, wäre der Verzicht auf Setter. Dann hätte man eine Klasse, deren Instanzen feste Werte darstellen. Die Instanzen sind also nicht veränderbar. Beim Geld kann man das sehr gut so sehen: 20 Euro sind 20 Euro. Die 20 Euro selbst kann man nicht verändern. Man kann diese ausgeben oder so, aber der 20 € Schein (um mal eine konkrete Darstellung zu sehen) verändert sich nicht.

Wie dann ein Wert intern gespeichert wird, ist dabei dann egal. Von mir aus die zehntel-Cent.

Aber 20€ + 1? Was sind 20 Äpfel + 1 Gurke? So eine add Methode wäre also nie die Addition eines int oder long oder float oder double oder so ... man addiert nur Geld. Dann kann man z.B. etwas bauen wie public Money add(Money... moneyToAdd) - dabei kommt dann aber eine neue Money Instanz bei raus. (Das Varargs muss natürlich nicht sein, aber es vereinfacht es teilweise)

Zu den Instanzen muss man aber kommen. Da kann man dann Factor Methoden bauen:
public static Money ofEuro(int)
public static Money ofCent(int)
...
Das kann man auch gerne zusammen fassen - dann kann man Euro und Cent angeben.

Das immutable hat diverse Vorteile z.B. bei Streams. Aber ich kann dann auch Dinge direkt setzen. Mein Auto kostet genau so viel, wie das Dein Auto: Ich weise einfach die Money Instanz deines Autos meinem Auto zu. Ich kann eine Referenz also an vielen Stellen nutzen.

Das nur um eine weitere Möglichkeit aufzuzeigen. Diese Möglichkeit enthält auch das, was hier mehrfach angesprochen wurde: Es gibt nicht auf Zwang zu Variablen auch Getter und Setter. Die gibt es nur, wenn diese wirklich benötigt werden. Und hier gibt es die nicht. Wobei es auch Methoden geben kann: getEuro(), getCent(), getDeciCent(), ... "Getter" besagt halt erst einmal, dass etwas geholt wird. Das besagt halt nicht, woher der Wert kommt, der dann zurück gegeben wird.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
W Getter/Setter Java Basics - Anfänger-Themen 4
KogoroMori21 Objektvariable anderer Klasse übernehmen, Getter/Setter Java Basics - Anfänger-Themen 11
T Verständnisfrage Objekt Getter Setter Java Basics - Anfänger-Themen 102
KogoroMori21 Getter und Setter Java Basics - Anfänger-Themen 5
S Klassen instanziieren und verwenden von Getter und Setter Java Basics - Anfänger-Themen 4
P Klasse hat keinen Zugriff auf getter/setter-Methoden eines Objektes Java Basics - Anfänger-Themen 9
V getter/setter Garage Java Basics - Anfänger-Themen 12
S getter, setter in abstrakter Klasse oder lieber Unterklassen Java Basics - Anfänger-Themen 4
topi Kapselung getter und setter Java Basics - Anfänger-Themen 5
D Setter/Getter für Instanzvariablen praktisch? Java Basics - Anfänger-Themen 19
S Getter/Setter - Variablenklasse ? Java Basics - Anfänger-Themen 5
S getter and setter Java Basics - Anfänger-Themen 12
L Getter und Setter Java Basics - Anfänger-Themen 2
M Generics getter und setter Methoden Java Basics - Anfänger-Themen 4
E Methoden Objekte in Methode aufrufen ohne getter und setter? Java Basics - Anfänger-Themen 1
L Klassen - Getter & Setter Methoden Java Basics - Anfänger-Themen 2
D Erste Schritte Java - Setter und Getter Java Basics - Anfänger-Themen 1
Z Getter/Setter NullPointer Exception Java Basics - Anfänger-Themen 6
K Klassen Setter/Getter Java Basics - Anfänger-Themen 3
F OOP Schleifen und Probleme mit Setter und Getter Java Basics - Anfänger-Themen 1
L Setter und Getter/Vererbung Java Basics - Anfänger-Themen 6
K Kapselung getter & setter Java Basics - Anfänger-Themen 11
J Frage zu Setter u. Getter Java Basics - Anfänger-Themen 7
T Variablen Getter-Setter vs Public Variable? Java Basics - Anfänger-Themen 5
Y Konstruktor - Setter/Getter Java Basics - Anfänger-Themen 3
N Klassen fragen zur getter und setter methode Java Basics - Anfänger-Themen 11
D Ab wann getter und setter Java Basics - Anfänger-Themen 2
K getter & setter Java Basics - Anfänger-Themen 6
C getter/setter Problem anscheinend Java Basics - Anfänger-Themen 13
G Erste Schritte Getter und Setter Java Basics - Anfänger-Themen 12
B Getter,Setter - Konstruktor überflüssig? Java Basics - Anfänger-Themen 26
N Sprite Methode (Getter, Setter, Konstruktor) Java Basics - Anfänger-Themen 9
S getter/setter aufrufen Java Basics - Anfänger-Themen 9
B Java getter/setter funktioniert nicht! Java Basics - Anfänger-Themen 7
X OOP Getter/Setter überschreiben den Wert ihrer Variablen nicht Java Basics - Anfänger-Themen 4
T Erste Schritte Verständnisfrage: Getter und Setter Methoden Java Basics - Anfänger-Themen 3
V public Variablen vs Getter + Setter Java Basics - Anfänger-Themen 4
F Getter und Setter Java Basics - Anfänger-Themen 4
lulas[]args getter/setter umstellung Java Basics - Anfänger-Themen 6
B Klassen Getter-Setter vor neuem Klassenaufruf - wie? Java Basics - Anfänger-Themen 20
N OOP Getter, Setter und andere Probleme Java Basics - Anfänger-Themen 8
A OOP Getter und Setter Java Basics - Anfänger-Themen 18
L Unterschied Konstruktor / Getter Setter Java Basics - Anfänger-Themen 13
L Setter und Getter für Arrays? Java Basics - Anfänger-Themen 4
N boolean bei Setter und getter methoden Java Basics - Anfänger-Themen 21
J Getter und Setter auch intern benutzen - guter Stil? Java Basics - Anfänger-Themen 31
Houly Setter/Getter MEthoden testen Java Basics - Anfänger-Themen 4
P OOP Getter&Setter Methoden funktionieren nicht Java Basics - Anfänger-Themen 7
H Setter-und-Getter-Konvention Java Basics - Anfänger-Themen 8
V Reflection API - getter und setter Java Basics - Anfänger-Themen 7
-horn- EINE setter/getter klasse aus mehreren klassen befüllen Java Basics - Anfänger-Themen 13
C Getter/Setter Java Basics - Anfänger-Themen 61
H Frage zu getter und setter Java Basics - Anfänger-Themen 5
S Unbenutzte/überflüssige Getter/Setter herausfinden? Java Basics - Anfänger-Themen 2
M getter/setter bei JTextField ? Java Basics - Anfänger-Themen 21
G warum Setter/Getter Java Basics - Anfänger-Themen 25
S In einer Liste auf getter und setter zugreifen Java Basics - Anfänger-Themen 6
Say Class scope und Instance scope und Getter nur selbstgeschrieben Methoden Java Basics - Anfänger-Themen 11
W Unterschiede bei Zugriff auf Objekt und Klassenvariablen über einen Getter? Java Basics - Anfänger-Themen 2
O Instanzattribut per Getter Methode zuweisbar, warum? Java Basics - Anfänger-Themen 8
P Klassenübergreifende Ausgabe mittels "getter" nicht möglich Java Basics - Anfänger-Themen 21
J Array über Getter erlangen Java Basics - Anfänger-Themen 34
M Getter einer PriorityQueue Java Basics - Anfänger-Themen 1
KopaCoda Getter mehrfach aufrufen -> ist das guter code? Java Basics - Anfänger-Themen 3
V Getter Methode Java Basics - Anfänger-Themen 38
T Extrahiertes Objekt durch Getter bekommen Java Basics - Anfänger-Themen 2
D Kapselung final Variablen mit Getter? Java Basics - Anfänger-Themen 2
A getter Java Basics - Anfänger-Themen 3
T Getter für Array Java Basics - Anfänger-Themen 4
J-Gallus Ein Getter bekommt eine anderen Type als er Return soll Java Basics - Anfänger-Themen 9
K Public Attribute oder getter - funktioniert leider beides hier nicht Java Basics - Anfänger-Themen 5
P getter Java Basics - Anfänger-Themen 1
M Getter Problematik mit ItemListener Java Basics - Anfänger-Themen 17
S Array und Getter-Methode Java Basics - Anfänger-Themen 2
Avarion Getter von Super-Klasse funktioniert nicht Java Basics - Anfänger-Themen 10
J Variable per Getter holen - wie ? Java Basics - Anfänger-Themen 2
D Getter Mehtode Unsicher Java Basics - Anfänger-Themen 6
M Problem mit getter, liefert nur alte Werte Java Basics - Anfänger-Themen 6
El_Lobo Methoden Zu viele Getter- und Settermethoden - geht das einfacher? Java Basics - Anfänger-Themen 3
G Generics kein Zugriff auf getter eines Objekts Java Basics - Anfänger-Themen 4
M OOP Aufruf vieler Getter Methoden abkürzen? Java Basics - Anfänger-Themen 7
MU5T4NG Getter und Setten bei GUI-Erstellung Java Basics - Anfänger-Themen 13
B Variablen keine Arrayübergabe für getter im Interface Java Basics - Anfänger-Themen 8
J int Wert mit getter holen und in String parsen Java Basics - Anfänger-Themen 5
O Universeller GETTER Java Basics - Anfänger-Themen 5
J Die Getter Methode Java Basics - Anfänger-Themen 6
E [Erledigt] Schöner Code zur Reduktion von unzähligen Getter-Methoden Java Basics - Anfänger-Themen 2
F 2 dimensionales Array getter Methode Java Basics - Anfänger-Themen 3
K Getter Java Basics - Anfänger-Themen 6
S JTextField in anderer Classe mit getter Methode auslesen. Java Basics - Anfänger-Themen 2
M if oder verschiedene getter Java Basics - Anfänger-Themen 31
I If / Else in Setter? Java Basics - Anfänger-Themen 8
M Methoden Zweidimensionaler Array mit Setter Methode ändern Java Basics - Anfänger-Themen 4
H Mit setter-Methode JLabel in einer andern Klasse ändern. Java Basics - Anfänger-Themen 40
C Setter-Methode mit final-Attribut Java Basics - Anfänger-Themen 9
M Gettter/Setter Methoden Klassenfelder kapselung und zugriff? Java Basics - Anfänger-Themen 1
JavaTalksToMe Kapselung Setter Frage Java Basics - Anfänger-Themen 15
kilopack15 Ist diese setter-Methode richtig? Java Basics - Anfänger-Themen 2
T setter im Konstruktor einbauen? Java Basics - Anfänger-Themen 8
F Setter Java Basics - Anfänger-Themen 4

Ähnliche Java Themen

Neue Themen


Oben