Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
... und finde ihn einfach nicht mehr
Es ging um Konstruktoren und Getter/Setter und wann man eher das eine und wann eher das andere verwendet. Ich hab unzählige Threads mittlerweile durch, aber diesen einen, in dem sich eine absolut geniale Zusammenfassung befindet, find ich leider nicht mehr ;( (Konstruktor und Getter/Setter sind auch blöde Suchbegriffe) - es war eine klasse und verständliche Zusammenfassung von einem User in dem Thread.
Hoffe, jemand weiß, welchen Thread ich meine und hat zufällig den Link.
In den FAQs hab ich leider auch nix gefunden. Ich weiß nur, dass ich vor 3, 4 oder 5 Wochen irgendwo einen Thread (wahrscheinlich im Anfänger-Forum, aber auch das ist nicht sicher) gelesen hab, der dann auf den Thread, den ich suche, verlinkt hat.
Der Beitrag ging um das Für und Wider von Konstruktoren und Getter/Setter, bzw. was man wann wohl eher in welchem Fall einsetzt. Und, ich glaub, einer der Foren-Gurus hier ist es gewesen, hat da mal irgendwo diese gute Zusammenfassung niedergeschrieben.
nee, leider auch nicht. Ich werd wohl nicht drum rum kommen, wirklich jeden einzelnen Thread zu lesen und auf entsprechende Links zu klicken :autsch:
Aber dennoch schon mal vielen lieben Dank für Deine Hilfe!
Willst du was Konkretes zu Konstrukturen / Gettern / Settern wissen? Weil dann könnte man probieren es nochmal zu erklären. Wenn du nicht genau weißt wonach du suchst kann so eine Suche sehr mühselig werden.
Finde auch du könntest deine Fragen hier stellen.. so schwierig ist das alles nicht.
Konstruktoren sollten ein gültiges Objekt erstellen, Ausnahmen sind JavaBeans, diese müssen einen Standardkonstruktor, Setter und Getter haben.
Falls man DI verwendet (Spring, Guice, etc.) hat man die Wahl zwischen Gettern/Settern und Konstruktoren die Werte setzen, da ist der Unterschied nicht mehr so groß, man spart sich einiges an "boilerplate" Code (Getter/Setter) wenn man es über den Konstruktor macht, und die Nutzer der Klasse wissen gleich, welche Parameter nicht optional sind.
Na ja, ich will doch nur die immer wieder gleiche Frage vermeiden, vor allem deshalb, weil ich die Antwort doch hier in dem Forum schon gelesen habe
Aber eigentlich wollte ich nur noch mal lesen, wann es sinnvoller ist Getter und Setter zu verwenden und wann man Konstruktoren nutzt?
Bitte jetzt nicht schreiben, dass es Situationen gibt, in denen Getter und Setter zu spät kommen, weil das Objekt nach
Java:
Regentropfen blub = new Regentropfen();
bereits eine Größe haben sollte und nicht erst die Größe mit einem Setter zugewiesen wird. Den Teil hab ich schon verstanden. Was ich suche war mehr eine Art Kochrezept, wann man besser Konstruktoren verwendet und wann sich Getter/Setter eignen.
Mir ist auch klar, dass es hier kaum ein Richtig und Falsch gibt, aber es gibt eben diese Erfahrungswerte, die die Gurus hier schon haben und davon wollte ich profitieren.
Ich bin zwar kein Guru, probiere es aber trotzdem mal:
Versuche Setter immer zu vermeiden. Nutze statt dessen komplett gekapselte (unveränderliche) Objekte. Ein Grund ist die Nebenläufigkeit (die dir momentan wahrscheinlich noch komplett egal ist), ein Anderer die Lesbarkeit/Nachvollziehbarkeit des Codes. Wenn ein Objekt an einer Stelle erzeugt wird, ist das viel verständlicher als die Konstruktion über einen größeren Zeitraum zu vollstrecken. Ein Beispiel:
Java:
new Objekt(param1, pram2, param3);
// vs.
Objekt o = new Objekt();
// irgendwelche Berechnungen für param1
Objekt param1 = ...
o.set(param1);
// noch mehr Berechnungen
Objekt param2 = ...
o.set(param2);
// und noch mehr
Objekt param3 = ...
o.set(param3);
Im ersten Fall ist klar erkenntlich, mit was für Daten ein Objekt gefüllt wird. Schlimm wird es im zweiten Fall wenn z.B. eine Exception auftritt. Das Objekt gibt es schon - es ist aber noch unvollständig. Bei falschem Exception-Handling wird schnell mit diesen Objekt weitergearbeitet.
Noch deutlicher wird es hier:
Java:
Objekt machWas(Objekt o) {
Objekt x = ...
o.set(x);
return o;
}
Wenn hier mehrere Threads aktiv sind fliegt dir das ganze System auseinander. Und selbst wenn es keine Threads gibt ist es verdammt schwer dem Ablauf des Codes zu folgen. Wenn du keine Setter erstellst, kann so etwas gar nicht erst auftreten. Lieber mit einer copy-Methode ein neues Objekt erzeugen und damit weiterarbeiten.
Nachrichten zwischen den Objekten tauscht du am besten über Observer/Listener aus (dafür kannst du dir mal MVC angucken - das ist ein Anwendungsfall bei dem man sehr gut damit arbeiten kann). Das sorgt auch dafür, dass du gleich mit Schnittstellen anstatt mit konkreten Implementierungen arbeitest (womit wir wieder bei Kapselung und Dependency Injection wären).
Wenn veränderliche Objekte benötigt werden, dann Setter nur nutzen wenn es nicht möglich ist diese Informationen schon bei der Konstruktion des Objekts anzugeben und ein Observer-/Listener-Konzept zu aufwendig wäre (was aber nur bei sehr kleinen Programmen der Fall ist).
Ich behaupte jetzt einfach mal, dass eine vernünftige Applikation es nicht nötig hat Setter zu benutzen. Funktional Programmiersprachen arbeiten sehr gut ohne diese und wenn man sich in einer imperativen Programmiersprache daran hält, kann man nicht viel falsch machen.
