OOP Zusammenfassen / vereinfachen von get; set;?

[membersound]

Hallo,

ich stelle mir grad folgende Frage:

gibt es in Java die Möglichkeit, so etwas zu machen?

@Entity
public class MyClass {
  private int i {get; set;}
}

Im Grunde sieht jede Entity ja gleich aus: Felder definieren, getter+setter schreiben (oder von der IDE generieren lassen). Aber es ist ja doch immer das selbe, dh es wiederholt sich sehr viel Code.
Wäre doch praktisch, wenn man das ganze mit get; set; einfach abkürzen könnte. Und der Compiler das dann richtig interpretiert.

Existiert sowas bereits?
Danke

 

[Marcinek]

In Java geht das nicht.

 

[HimBromBeere]

Kannst dir höchstens so ´ne Art Präcimpiler schreiben, ähnlich wie in C/C++, wenn du si scharf auf die Abkürzung bist... viel Spaß

 

[Schandro]

Beispielsweise Roo erstellt dir automatisch getters/setters (und auch toString...) mithilfe von AOP, das heisst dein eigentlicher Quellcode bleibt frei von getters/setters usw., wenn du aber was ändert generiert dir Roo im Hintergrund automatisch passenden AOP Code der die getters/setters usw. während des compilens zu den Klassen hinzufügt.

Die IDE die getters/setters generieren zu lassen dauert hingegen mehrere Sekunden....

 

[maki]

Project Lombok löst das mit Annotationen:
@Getter and @Setter

 

[javapower]

In Eclipse kann man sich die getters und setters ebenfalls automatisch generieren lassen.

 

[...ButAlive]

Naja statt:

class Foo{
     private int bar;
     public int getBar(){return bar;}
     public void setBar(int bar){this.bar = bar;}
}

kann man gleich folgendes schreiben:

class Foo{
   public int bar;
}

Ok dann geht natürlich folgendes nicht mehr:

class CoolesFoo extends Foo{
    @Override
    public void setBar(int bar}{
       throws UnsupportedOperationException();
    }
}

Was ich eigentlich meine ist, dass die Kunst darin liegt, die Datentypen so immutable wie möglich zu machen und die Felder zu kapseln, dann kann man sich nämlich Getter/Setter-Orgien sparen.

P.S.: Entschuldigung dass da etwas Sarkasmus mitschwingt, hab mich den ganzen Tag darüber geärgert, dass man XJC nicht dazu bringen kann, aus einem Schema Klassen ohne Setter zu generieren. Der Ratschlag dass Immutables erstrebenswert sind ist aber ernst gemeint.

 

[HimBromBeere]

class Foo{
   public int bar;
}

Was bitte ist daran "immutable". Das ist mal sowas von "mutable", mehr geht schon praktisch nicht mehr. Was du u.U. meinst, ist der Integer-Wrapper, der ist tatsächlich immuatble.
Instanzvariablen sollten niemals public gemacht werden, sondern immer so privat wie möglich (also vorzugsweise private, protected geht aber auch...). Daher ist das Erstellen von Getter und Setter schon fast existenziell wenn´s um OOP geht...

EDIT: Ich nehme mal an, dein Sarkasmus ist ein wenig verschollen... den solltest du evtl. etwas deutlicher rüberbringen...

 

[maki]

immutable etc. pp. ist praktisch für Objekte, aber nicht für Datenstrukturen (ohne verhalten), sieht man ja ganz gut an JavaBeans.

Tatsächlich sind JavaBeans keine "echten" Objekte sondern nur Datenstrukturen, es wäre so gesehen vollkommen egal ob public Attribute oder eben Getter & Setter für alle Attribute die Konvention gewesen wäre, nimmt sich gar nix

 

[bygones]

immutable etc. pp. ist praktisch für Objekte, aber nicht für Datenstrukturen (ohne verhalten), sieht man ja ganz gut an JavaBeans.

Tatsächlich sind JavaBeans keine "echten" Objekte sondern nur Datenstrukturen, es wäre so gesehen vollkommen egal ob public Attribute oder eben Getter & Setter für alle Attribute die Konvention gewesen wäre, nimmt sich gar nix

das Problem ist eher wann das eine, wann das andere. Das mag fuer manchen nicht so trivial sein. Daher wuerde ich an der Regel des kleinsten access modifiers festhalten und nur getter setter nehmen, wenn diese wirklich von einem Verwender gebraucht werden.

 

[schalentier]

Was bitte ist daran "immutable". Das ist mal sowas von "mutable", mehr geht schon praktisch nicht mehr. Was du u.U. meinst, ist der Integer-Wrapper, der ist tatsächlich immuatble.
Instanzvariablen sollten niemals public gemacht werden, sondern immer so privat wie möglich (also vorzugsweise private, protected geht aber auch...). Daher ist das Erstellen von Getter und Setter schon fast existenziell wenn´s um OOP geht...

EDIT: Ich nehme mal an, dein Sarkasmus ist ein wenig verschollen... den solltest du evtl. etwas deutlicher rüberbringen...

Ruhig Blut, sowas kann man tatsaechlich machen, wenn man z.B. das Play! Framework hernimmt. Dort werden aus den public Feldern per ByteCode Manipulation Getter/Setter generiert und alle Zugriffe entsprechend ersetzt. Der Vorteil ist, man spart nicht nur das ausschreiben selbiger, sondern kann auch noch so auf die Felder zugreifen, wie man das evtl. von anderen Sprachen her gewoehnt ist:

Foo foo = new Foo();
foo.bar = 42;
System.out.println( foo.bar );

Will man einen speziellen Setter haben, implementiert man den ganz so wie ueblich.

Play framework - The domain object model

 

[...ButAlive]

Was bitte ist daran "immutable". Das ist mal sowas von "mutable", mehr geht schon praktisch nicht mehr.

Sorry, da habe ich mich vielleicht falsch ausgedrückt. Was ich meine, ist das ich noch nie wirklich den Sinn dahinter verstanden habe, wieso ich eine Variable als als privat zu deklarieren und dann trotzdem die ganze Welt per setter den Wert manipulieren lasse, ohne irgendwelche ristriktionen darauf, da kann man meiner Meinung nach die Variable auch gleich public machen.

Früher war es vielleicht nötig für manche Tools setter und getter auf alles zu machen, aber die meisten modernen Sachen wie z.B. JAXB oder JPA können auch mit Feldern umgehen, daher fallen für mich viele Argumente alle Sachen per getter und setter verfügbar zu machen weg.

 

[HimBromBeere]

OK... dann hab ich deinen "Sarkasmus" doch tatsächlich richtig interpretiert... war aber schwer

 

[gassst]

Instanzvariablen sollten niemals public gemacht werden, sondern immer so privat wie möglich (also vorzugsweise private, protected geht aber auch...). Daher ist das Erstellen von Getter und Setter schon fast existenziell wenn´s um OOP geht...

Immer mit der Ruhe, prinzipiell hast du recht, dass öffentliche Member meistens schlechtes Design sind, getter und setter sind allerdings mindestens genauso übel und haben mit OOP erst recht nichts zu tun. Wenn ich Datenstruktur-Klassen habe und vor der Entscheidung stehe ob ich mir lieber 10 setter und getter generieren lasse oder die Felder öffentlich mache, bin ich mit der zweiten Option meist glücklicher.

 

[Schandro]

... ohne irgendwelche ristriktionen darauf...

ja, WENN dieses Feld keine Restriktionen hat und du dir 100% sicher bist das es auch in Zukunft nie irgendwelche haben wird, DANN kannst du getter/setter weglassen....
Aber sowas weiss man halt nie...

 

[diggaa1984]

Wenn ich Datenstruktur-Klassen habe und vor der Entscheidung stehe ob ich mir lieber 10 setter und getter generieren lasse oder die Felder öffentlich mache, bin ich mit der zweiten Option meist glücklicher.

Na da nutz ich lieber gleich setter un getter, um bei eventuell kommenden Einschränkungen nur die betreffende Klasse zu ändern und nich sämtliche Aufrufe dazu. Die Kontrolle was rein und raus geht is nie verkehrt.

 

[...ButAlive]

ja, WENN dieses Feld keine Restriktionen hat und du dir 100% sicher bist das es auch in Zukunft nie irgendwelche haben wird, DANN kannst du getter/setter weglassen....
Aber sowas weiss man halt nie...

Es ist nicht so, dass ich alle meine Felder public mache. Hauptsächlich geht es mir darum, dass man setter und getter so sparsam wie möglich einsetzt und nicht einfach mal in der IDE generate getter/setter für alle Felder klickt. Meistens braucht man das gar nicht. Ich persönlich verzichte mittlerweile so weit es geht auf setter und erstelle mir lieber ein neues Objekt wenn sich etwas ändert. Auch getter braucht man nicht für alles.

Hauptsächlich mach(t)en getter und setter in DTOs oder Entitäten Sinn, da geht es darum eine Datenstruktur zu haben um sie von A nach B zu schieben. Solange es nur darum geht Daten geschickt zu verpacken und die Klassen keine Businesslogik haben, finde ich es vollkommenden legitim public Felder zu verwenden.

Ich finde auch:

foo.bar = "Test";

schöner zu lesen und schreiben als:

foo.setBar("Test");

Das mit den Restriktionen kann man doch mit der Validation-API lösen und als Annotationen an die einzelnen Felder schreiben.

 

[DStefan]

Sorry, da habe ich mich vielleicht falsch ausgedrückt. Was ich meine, ist das ich noch nie wirklich den Sinn dahinter verstanden habe, wieso ich eine Variable als als privat zu deklarieren und dann trotzdem die ganze Welt per setter den Wert manipulieren lasse, ohne irgendwelche ristriktionen darauf, da kann man meiner Meinung nach die Variable auch gleich public machen.

Früher war es vielleicht nötig für manche Tools setter und getter auf alles zu machen, aber die meisten modernen Sachen wie z.B. JAXB oder JPA können auch mit Feldern umgehen, daher fallen für mich viele Argumente alle Sachen per getter und setter verfügbar zu machen weg.

Es geht ja nicht nur darum, dass Werte geändert werden, sondern von wo aus sie geändert werden. Solange du keine Probleme hast, magst du mit public Variablen durchkommen. Aber falls aus irgend einem Grund Fehler mit diesen Variablen auftreten, hast du tausend Stellen, an denen sie geändert werden. Bei einem Setter gibt es aber nur eine Stelle.

Es gibt Leute, die sogar in der Klasse selbst ausschließlich Setter aufrufen, um dem aus dem Weg zu gehen. Ich finde das Argument verständlich - auch wenn ich selbst noch nicht ganz so weit bin


Stefan.

 

[maki]

das Problem ist eher wann das eine, wann das andere. Das mag fuer manchen nicht so trivial sein. Daher wuerde ich an der Regel des kleinsten access modifiers festhalten und nur getter setter nehmen, wenn diese wirklich von einem Verwender gebraucht werden.

Das ist sicherlich wahr, oft habe ich den Eindruck dass Leute den Unterschied gar nicht kennen.

Wenn man für alle Attribute Getter & Setter macht hat man wohl eine Datenstruktur , kein Objekt

Ich kann ButAlive absolut nachvollziehen, Getter/Setter helfen einem wenig bei Datenstrukturen, denn diese enthalten weder verhalten, noch validieren sie und bieten im Normalfall keine Kapselung (zumindest nicht ohne weiteres), sind fast(!) genauso gut/schlecht wie public Instanzvariablen, diese Konvention wurde durch die JavaBeans Spec. festgelegt.
Ein Beispiel für einen Vorteil ist eben, dass man andere Dinge machen kann in den Methoden, wie zB. einen PropertyChangeSupport Event feuern (ob die Umsetzung mit PropertyChangeSupport und Strings wirklich elegant ist ist ein anderes Thema).

"Echte" Objekte dagegen haben nicht Getter & Setter für alle Attribute und meist auch verhalten, da darf man dann gerne die OOD Regeln anwenden

Es gibt Leute, die sogar in der Klasse selbst ausschließlich Setter aufrufen, um dem aus dem Weg zu gehen.

Aber sicherlich nicht bei Datenstrukturen

 

[...ButAlive]

Es geht ja nicht nur darum, dass Werte geändert werden, sondern von wo aus sie geändert werden. Solange du keine Probleme hast, magst du mit public Variablen durchkommen. Aber falls aus irgend einem Grund Fehler mit diesen Variablen auftreten, hast du tausend Stellen, an denen sie geändert werden. Bei einem Setter gibt es aber nur eine Stelle.

Aber es gibt 1000 stellen die den Setter aufrufen. Wo ist denn der Unterschied? Sich ändernde Werte sind immer schwierig zu handhaben. Daher plädiere ich ja auch für Immutables.

Prinzipiell hast du 2 Möglichkeiten Datenstrukturen zu validieren. Dann wenn ein Wert gesetzt wird oder dann wenn das Objekt verwendet werden soll. Das was du meinst ist die erste Möglichkeit. Was ich meine ist die zweite.

Nehmen wir mal an du implementierst ein Forum, da gibt es dann folgende Datenstruktur:

class Post
{
    private User user;
    private String title;
    private String content;
    
    public Post(User user, String title, String content){
         if(user==null)
             throw new IllegalArgumentException("User darf nicht leer sein");
          this.user = user;
         ...
     }        
    //Getter und Setter
}

Jetzt hast du die Geschäftsregel ein Post kann ohne User und Title nicht gespeichert werden. Soweit schön und gut.

Irgendwann kommst du auf die Idee und sagst, Postings sollten als Entwurf gespeichert werden können, dazu ist braucht es aber noch keinen Titel. Das kannst du nicht mehr in den Settern abbilden.

Wann ein Objekt valide ist hängt vom Kontext ab in dem sie benutzt werden, daher müssen die Klassen mit der Logik die Validierung übernehmen. Wenn du jetzt nicht mehr in der Lage bist im Setter zu sagen ob der Wert passt oder nicht, ist es vollkommend egal wie man den Wert ändern lässt, ob nun über einen Setter oder über das Feld direkt.

Der andere Weg ist, dass man das Objekt gar nicht ändern kann und für die unterschiedlichen Kontexte unterschiedliche Factory-Methoden zur Verfügung stellt. Das ist der Weg den ich bevorzuge.

 

[DStefan]

Aber es gibt 1000 stellen die den Setter aufrufen. Wo ist denn der Unterschied? Sich ändernde Werte sind immer schwierig zu handhaben. Daher plädiere ich ja auch für Immutables.

Ich habe mich darauf bezogen, dass du (sinngemäß) schreibst, wenn man einen Setter habe, können man die Variable auch gleich public machen. Dass unveränderbare Objekte (vor allem in Java) sehr sinnvoll sind, bestreite ich gar nicht. Bloß dass ein Setter "dasselbe" wie eine public Variable ist.

Es ist, finde ich, ein verdammt großer Unterschied, ob 1000 Stellen einen Setter aufrufen (die Variable aber nur dort geändert wird) oder ob diese 1000 Stellen direkt auf die Variable zugreifen.


Stefan.

 

[maki]

Es ist, finde ich, ein verdammt großer Unterschied, ob 1000 Stellen einen Setter aufrufen (die Variable aber nur dort geändert wird) oder ob diese 1000 Stellen direkt auf die Variable zugreifen.

Es macht wirlich gar keinen Unterschied wenn der Setter wirklich nur "setted"

Immutables sind aber auch nicht immer möglich, zB. bei Entitäten.
Das heisst aber nicht, dass man in Entitäten autom. für alle Attribute einen Setter braucht.
Insbesondere macht es oft Sinn, Entitäten aus Immutables & Mutables zusammenzusetzen, die Entität an sich ist dann eben mutable.

 

[HimBromBeere]

Jetzt ist schon so viel gesagt worden, da fällt´s nun auch nicht mehr auf, wenn ich was Dummes erzähle... also geb ich auch noch meinen Senf dazu ab.

Ich muss DStefan schon zum Teil zustimmen, dass es einen Unterschied macht, einen Setter zu verwenden oder "1000mal im Code die als public deklarierte Variable direkt zu verändern". Der Grund ist einfach die Wartung des Codes: wenn ich mich tatsächlich irgendwann einmal besonnen und festgestellt habe, dass ich evtl. doch lieber eine Verwaltung der Werte vornehmen möchte (z.B. irgendwelche Restriktionen), dann muss ich das im Falle eines Setters wirklich NUR DORT ändern. Bei ´ner public Variable muss ich jetzt alle 1000Stellen suchen, die diese anfassen und überall die neu enstandene Bedingung manuell hinzufügen... na Prost Neujahr:lol:
Also solange man wirklich einen Stter nur zum Setzen einsetzt, ist es völlig Latte, wie man das erreicht. Aber hinsichtlich evtl. Fortführungen würde ich (vorausschauend wie ich eben bin) immer einen Setter verwenden, man weiß ja nie, wofür man den mal braucht...

 

[schalentier]

Refactoring -> Encapsulate Fields

Man koennte ja mal die gewagte These aufstellen, dass man grundsaetzlich mit public Feldern anfaengt, und nur bei Bedarf mittels Encapsulate Fields sich die entsprechend notwendigen Getter/Setter generiert.

Problematisch waeren vermutlich irgendwelche Bytecode Manipulatoren/Reflection Frameworks, die eben auf die Getter/Setter angewiesen sind.

Aber ansonsten wuerde man ziemlich viel nervigen und u.U. auch stoerenden Getter/Setter-Code sparen...

mh...

 

[Tobse]

Also in C# gits irgendwie sowas:

class Foo {
    public double foo
    {
        get { return foo }
        set { foo=value }
    }
}

die man mit nem Vor-Compilierer umsetzen könnte. Was ich manchmal ganz nützlich fände sind felder, die von aussen zwar gelesen, also [c]instance.field[/c] aber nur über den setter bzw. garnicht gescrieben werden dürfen. Gibts in C# auch, z.B. Array.Length. Aber genug von M$.
Ich persönlich find die IDE-Generierten getter/setter am sinnvollsten.

 

[mvitz]

Refactoring -> Encapsulate Fields

Man koennte ja mal die gewagte These aufstellen, dass man grundsaetzlich mit public Feldern anfaengt, und nur bei Bedarf mittels Encapsulate Fields sich die entsprechend notwendigen Getter/Setter generiert.

Problematisch waeren vermutlich irgendwelche Bytecode Manipulatoren/Reflection Frameworks, die eben auf die Getter/Setter angewiesen sind.

Aber ansonsten wuerde man ziemlich viel nervigen und u.U. auch stoerenden Getter/Setter-Code sparen...

mh...

Mit der Einschränkung, dass das natürlich nur funktioniert, wenn man selber die Kontrolle über alle Aufrufenden Klassen hat.

 

[schalentier]

Jo, ne, is ne bekloppte Idee ;-)

1. Jeder Java Entwickler waere total verwirrt.
2. Man wuerde den Zugriff auf klassenfremde Properties mal mit Setter/Getter mal direkt mit = machen -> Inkonsistent, IDE Unfreundlich.

 

[gasssst]

wenn ich mich tatsächlich irgendwann einmal besonnen und festgestellt habe, dass ich evtl. doch lieber eine Verwaltung der Werte vornehmen möchte (z.B. irgendwelche Restriktionen), dann muss ich das im Falle eines Setters wirklich NUR DORT ändern. Bei ´ner public Variable muss ich jetzt alle 1000Stellen suchen, die diese anfassen und überall die neu enstandene Bedingung manuell hinzufügen... na Prost Neujahr:lol:

Das ist ein Trugschluss - denk das Szenario mal zu Ende:
- du fügst irgendwelchen Validationscode in eine setter Methode ein
- was machst du bei falschen übergebenen Werten? Eine Exception werfen? Den Wert ignorieren?
- du entscheidest dich eine Exception zu werfen (definitiv sinnvoller als Möglichkeit #2): jetzt hast du 1000 Stellen im Code, wo du eine setter Methode aufrufst, die eventuell eine Runtime Exception wirft.
- Was machst du? Entweder Validationslogik an die 1000 Stellen kopieren um sicherzustellen, dass nur valide Werte in die setter Methode gelangen, oder 1000 mal eine Exception fangen oder 1000 mal auf gut Glück den Wert setzen - oder eine Mischung, was von allen Möglichkeiten wohl die schlechteste wär, da der Code noch um ein vielfaches mehr undurchsichtiger wird.

Was lernt man aus der Sache?
Das Argument für setter Methoden als Alternative zu public Feldern man könne damit (nachträglich oder von vornherein) Logik in setter Methoden (z.B. Validation der Werte) einbauen ist nonsens. Solche Logik gehört einfach nicht dorthin. Entweder eine Klasse ist eine Datenstruktur/Entität, oder verwaltet Logik, wie Wertevalidation. Wenn ich beides in einer Klasse habe, kann ich von einem viel größeren Designproblem ausgehen, als manche Leute jemals public Felder zu einem aufzublähen schaffen würden.

Nichtsdestotrotz freu ich mich, dass nach etlichen Jahren auch hier in dem Forum nicht mehr auto- und dogmatisch mit Dreck geworfen wird, wenn man Sinn und Unsinn von getter/setter Methoden anzweifelt.

 

[Schandro]

Das ist ein Trugschluss - denk das Szenario mal zu Ende:
- du fügst irgendwelchen Validationscode in eine setter Methode ein
- was machst du bei falschen übergebenen Werten? Eine Exception werfen? Den Wert ignorieren

Deine ganze argumentation basiert auf einer Annahme die nur einen Teil der Fälle ausmacht, sagt also nichts über den insgesamten Wert von gettern/settern aus...

Ich persönlich arbeite immer mit gettern/settern, es spart Tipparbeit. Den das zugreifen auf public Membervariablen wird man an einigen Stellen eh wieder ersetzen, und getter/setter zu generieren dauert bei ner guten IDE ne halbe Sekunde, wenn man die Tastenkombination auswendig weiss...
Außerdem ist es einfach Standard, genauso wie du auch nie auf die Idee kommen würdest den ersten Buchstaben einer Klasse klein zu schreiben...

 

[...ButAlive]

Ich persönlich arbeite immer mit gettern/settern, es spart Tipparbeit. Den das zugreifen auf public Membervariablen wird man an einigen Stellen eh wieder ersetzen, und getter/setter zu generieren dauert bei ner guten IDE ne halbe Sekunde, wenn man die Tastenkombination auswendig weiss...

Das ist ein interessanter Aspekt. Du hast natürlich recht, wenn sich mal was ändert muss man wirklich weniger tippen.

Ich bin der Meinung, dass bestehender Code wesentlich öfter gelesen, als geändert wird. Dabei halte ich getter/setter für Code-Noise, also weißes Rauschen das keinen oder kaum Mehrwert bringt. Pro Feld kommen mindestens nochmal 6 Zeilen Code für getter und setter hinzu. Wenn man Glück hat stehen auch noch hilfreiche generierte Java-Doc-Kommentare wie:

/**
 * Returns the value of foo
 **/

Mal angenommen, eine Klasse hat 10 Member, für alle gibt es getter und setter. Außerdem hat die Klasse noch eine Methode die wirklich was macht und zufällig auch mit get anfängt. Such die mal. Wenn ich mir fremden Code anschaue, ärgere ich mich regelmäßig darüber.

Bei der ganzen Diskussion geht es mir ja nur um Datenstrukturen, wie z.B. Entitäten oder Klassen für Jaxb, generell bin ich natürlich auch gegen public-Members.

Vielleicht gibt es ja auch einen Mittelweg, was haltet ihr von:

• Alle Felder sind package-private
• getter werden generiert.
• Alle Klassen die direkt an den Datenstrukturen manipulieren können, müssen im selben Package liegen, für alle anderen sind die Datenstrukturen immutable.

 

[gasssst]

Deine ganze argumentation basiert auf einer Annahme die nur einen Teil der Fälle ausmacht, sagt also nichts über den insgesamten Wert von gettern/settern aus...

Stimmt, darum hab ich meine Argumentation ja auch unter das Zitat geschrieben. Nichtsdestotrotz würde mich interessieren mit welchen anderen sinnvollen use-cases für getter/setter du im Kopf hast.

Ich persönlich arbeite immer mit gettern/settern, es spart Tipparbeit. Den das zugreifen auf public Membervariablen wird man an einigen Stellen eh wieder ersetzen, und getter/setter zu generieren dauert bei ner guten IDE ne halbe Sekunde, wenn man die Tastenkombination auswendig weiss...
Außerdem ist es einfach Standard, genauso wie du auch nie auf die Idee kommen würdest den ersten Buchstaben einer Klasse klein zu schreiben...

Code generieren, weil:
- es schnell geht
- man ihn später vielleicht mal gebrauchen könnte
- es vermeintlich Standard sei (???)

ist schonmal prinzipiell keine gute Idee und auch keine gute Argumentation, ungeachtet worum es überhaupt geht.

 

[Schandro]

Code generieren, weil:
- es schnell geht
- man ihn später vielleicht mal gebrauchen könnte
- es vermeintlich Standard sei (???)

ist schonmal prinzipiell keine gute Idee und auch keine gute Argumentation, ungeachtet worum es überhaupt geht.

Und so hat jeder seine eigene Meinung, ich find Einheitlichen und Standatisierten Code schöner, wenn du lieber deine eigene Art des programmierens benutzt mit dem deine Kollegen eventuell nicht zurechtkommen oder es eh wieder refractorieren, schön für dich
Und das getters/setters Vorteile haben brauch ich hier wohl niemanden erklären...

Dieser Thread wird übrigens langsam ziemlich sinnlos, wir reden hier über getters und setters, mehr nicht. Es gibt tausendmal wichtigere Themen...

 

[gassst]

Und das getters/setters Vorteile haben brauch ich hier wohl niemanden erklären...

Doch ich bitte darum, denn das ist das Thema dieses Threads.

Dieser Thread wird übrigens langsam ziemlich sinnlos, wir reden hier über getters und setters, mehr nicht. Es gibt tausendmal wichtigere Themen...

Wieso wird der Thread sinnlos? getter und setter Methoden sind Thema dieses Threads. Wenn du nicht darüber diskutieren willst frag ich mich warum du in die Diskussion eingstiegen bist, aber nicht auf die Argumente anderer Posts eingehst.

 

[...ButAlive]

Wieso wird der Thread sinnlos? getter und setter Methoden sind Thema dieses Threads. Wenn du nicht darüber diskutieren willst frag ich mich warum du in die Diskussion eingstiegen bist, aber nicht auf die Argumente anderer Posts eingehst.

Das Thema war ursprünglich wie man getter und setter zusammenfassen kann, vermutlich der Übersichtlichkeit halber. Meine Aussage dazu war, wenn die getter und setter nur getten und setten kann man sie sich auch sparen. Dadurch kam die ganze Diskussion ins Rollen.

Mittlerweile glaube ich auch, dass wir uns genug dazu ausgetauscht haben und es somit gut ist. Die Wahrheit liegt wahrscheinlich irgendwo in der Mitte, und wie immer gilt, man sollte beim Programmieren das Gehirn einschalten und von Fall zu Fall unterscheiden.

Dafür werden wir ja auch gut bezahlt und wenn es einfach wäre könnte es ja jeder .

 

[Schandro]

Wieso wird der Thread sinnlos? getter und setter Methoden sind Thema dieses Threads. Wenn du nicht darüber diskutieren willst frag ich mich warum du in die Diskussion eingstiegen bist, aber nicht auf die Argumente anderer Posts eingehst.

Das Thema dieses Threads war es wie man die automatisch generieren oder mit einer kürzeren Syntax schreiben kann, meine Antwort darauf war als beispiel Roo / AspectJ.

 

[maki]

Verstehe ehrlich gesagt nicht warum man nun über das Thema dieses Threads diskutieren sollte wenn das seit Post 7/8 um den Sinn/Unsinn von Getter/Setter diskutiert, wer meint dass er nichts mehr sagen möchte, sollte dies einkfach tun.

Sinnlos ist dieser Thread imho auch nicht, was m.E. fehlt ist die Einsicht das wir offensichtlich nicht alle von denselben Sachen sprechen, mutable/immutable, getter/setter, Objekte/Datenstrukturen, etc.

Hier noch mal mein Senf *g*

- Wer meint dass "dumme" Getter und Setter autom. OOP ist und mehr Kontrolle verleihen hat das missverstanden, keine Kapselung, kein Information hiding
- Wer meint dass Datenstrukturen immutable sein sollten hat das missverstanden

Die Frage ob Getter/Setter für alles oder immutable sollte sich eigentlich (?) nicht stellen imho.

Ansonsten muss ich gasssst zustimmen, autom. immer Getter/Setter zu verwenden ist keine Gute Sache, aber in Java gibt es nunmal die JavaBeans (=Datenstrukturen, nicht OOP) Konventionen, manchmal muss man sich daran halten.