Gegenteil von Setter-Methoden

Diskutiere Gegenteil von Setter-Methoden im Java Basics - Anfänger-Themen Forum

12
  1. #1
    propra


    Gegenteil von Setter-Methoden

    Hallo zusammen,

    manchmal benötige eine Variable, um anzuzeigen, ob etwas gesetzt wurde. Z.B., ob etwas ausgewählt wurde.
    Dann muss ich, wenn ich die Auswahl aufheben möchte, natürlich auch diesen Wert löschen.
    Also kommt so etwas hier heraus:
    Java Code:
    1. public void setIsSomethingSet(boolean bool) {
    2. somethingToSet = bool;
    3. }

    Jetzt empfinde ich diese Konstruktion als komisch und das ist eigentlich oft ein Zeichen dafür, dass es falsch ist bzw. cleverer gelöst werden kann.
    Kann mir jemand verraten, wie man solche Situationen am besten löst?

    Vielen Dank

  2. #2
    Sym

    Java Code:
    1. public void setSomethingToSet(boolean bool) {
    2. somethingToSet = bool;
    3. }


    Das is lässt man in der Regel weg.

  3. #3
    SlaterB

    grundsätzlich besteht natürlich auch die Möglichkeit, in der Variablen selbst das Nicht-Gesetzt-Seit auszudrücken,
    durch null-Wert oder eine bestimmte Konstante,
    für primitive Datentypen sicherlich schwieriger, da gibts noch 0 oder -1, bei boolean wirds haarig

  4. #4
    Gast2

    Wenns dir nur darum geht die Variable somethingToSet "umzudrehen" dann könnte man auch sowas machen:
    Java Code:
    1. public void flipSomething() {
    2. something = !something;
    3. }

    Dann muss der Aufrufer sich nicht darum kümmern den aktuellen Status zu holen.

    Ansonsten, siehe Syms antwort. Das ist dann nen normaler setter für nen boolean wert.

  5. #5
    nillehammer

    Bei Booleans bietet es sich an, statt der setter-Syntax einfac zwei Methoden enable und disable zu bauen. Etwa so:
    Java Code:
    1.  
    2. public class MyClas {
    3.  
    4. private boolean myBoolean;
    5.  
    6. /* Setter und Getter nach Bean-Konvention */
    7. public void setMyBoolean(final boolean theBoolean) {
    8. this.myBoolean = theBoolean;
    9. }
    10.  
    11. public boolean getMyBoolean() {
    12. return this.myBoolean;
    13. }
    14.  
    15. /* Bei booleans darf der "getter" auch mit "is" beginnen, also: */
    16. public boolean isMyBoolean() {
    17. return this.myBoolean;
    18. }
    19.  
    20. /* Und nun die Schalter-Methoden */
    21. public void enableMyBoolean() {
    22. this.myBoolean = true;
    23. }
    24.  
    25. public void disableMyBoolean() {
    26. this.myBoolean = false;
    27. }
    28.  
    29. public void flipMyBoolean() {
    30. this.myBoolean = !this.myBoolean;
    31. }
    32.  
    33. }

  6. #6
    bygones

    @nillehammer
    6 methoden fuer ein boolean ?!

    mhm

    Java Code:
    1.  
    2. public class MyClas {
    3. private boolean myBoolean;
    4.  
    5. public boolean isMyBoolean() {
    6. return this.myBoolean;
    7. }
    8.  
    9. public void setMyBoolean(final boolean theBoolean) {
    10. this.myBoolean = theBoolean;
    11. }

    mehr brauchts nicht.

    selbst bei flipMyBoolean bin ich nicht so ueberzeugt, da der aufrufer keine ahnung hat in welchen Zustand sich myBoolean befindet und es gewiss zu code ala
    Java Code:
    1.  
    2. if (myClass.isMyBoolean()) {
    3. myClass.flipMyBoolean();
    4. }

    kommt (bzw mit der negation).

  7. #7
    Gast2

    Ja, wenns zu so nem Code kommt, dann ist nen normaler setter sicherlich die bessere Wahl
    Es kommt halt wie gesagt drauf an in welchem Kontext man den boolean nutzt. Du hast aber recht, in der Regel tuts nen gewöhnlicher setter.

  8. #8
    nillehammer

    Zitat Zitat von bygones
    @nillehammer
    6 methoden fuer ein boolean ?!
    propra hat nach möglichen Alternativen zu der normalen Setter-Syntax gefragt. Die hab ich genannt. Was er davon benutzt (sicher nicht alles), kann er sich dann selbst aussuchen. Und flips hab ich im Zusammenhang mit GUI-Elementen, die man auf- und zuklappen kann schon selbst oft benutzt. Da ist es mir nämlich egal, wie der aktuelle Zustand ist, ich will einfach, dass er sich ändert.

  9. #9
    HimBromBeere


    Warum kümmerst du dich um die Verwaltung des Wertes (gesetzt/ nicht gesetzt) nicht in der set-Funktionen deines Objektes?
    Wenn du z.B. eine Variable [C]int groesse[/C] hast und eine [C]boolean bSet = false[/C]
    dann schreibst du
    Java Code:
    1.  
    2. void setGroesse(int groesse) {
    3. this.groesse = groesse;
    4. this.bSet = true;
    5. }
    6.  
    7. boolean isSet() {return this.bSet;}
    8. void disable() {this.bSet = false;}


    wenn du dann in einer Auswahl eine andere Option auswählst, musst du nur mit diable() die aktuelle verwerfen...

  10. #10
    bygones

    Zitat Zitat von nillehammer Beitrag anzeigen
    propra hat nach möglichen Alternativen zu der normalen Setter-Syntax gefragt.
    er hat nicht nach Alternativen gefragt, sondern wie man es am besten loesen kann.

    Zitat Zitat von nillehammer Beitrag anzeigen
    Und flips hab ich im Zusammenhang mit GUI-Elementen, die man auf- und zuklappen kann schon selbst oft benutzt. Da ist es mir nämlich egal, wie der aktuelle Zustand ist, ich will einfach, dass er sich ändert.
    Und das mit der GUI ist schon richtig, nur ist das auch nur dort und sollte auch nur dort bleiben

  11. #11
    nillehammer

    Zitat Zitat von bygones
    er hat nicht nach Alternativen gefragt, sondern wie man es am besten loesen kann.
    Hab die Frage nochmal genau gelesen, hast Recht.
    Zitat Zitat von bygones
    Und das mit der GUI ist schon richtig, nur ist das auch nur dort und sollte auch nur dort bleiben
    Habe mir gerade das Gehirn zermartert, ob ich das irgendwoanders schonmal benutzt habe. Mir fällt außer GUI nichts ein. Aber ganz ausschließen möchte ich es nicht, dass es auch woanders sinnvoll sein kann.

  12. #12
    hdi


    @HimBrombeere

    Java Code:
    1. void setGroesse(int groesse) {
    2. this.groesse = groesse;
    3. this.bSet = true;
    4. }
    5.  
    6. boolean isSet() {return this.bSet;}
    7. void disable() {this.bSet = false;}


    Das ist nich cool. Mit solchen Methoden kann man sich schnell eklige Logik-Bugs einfangen. Ein Setter (bzw allgemeine jede Methode) sollte keine unerwarteten Seiteneffekte haben. Wenn ich setGroesse() aufrufe dann will ich dass sich die Größe ändert - nicht mehr, nicht weniger. Außerdem ist das redundant, wenn du zwei Variablen hast die eigentlich das selbe ausdrücken.

    grundsätzlich besteht natürlich auch die Möglichkeit, in der Variablen selbst das Nicht-Gesetzt-Seit auszudrücken,
    durch null-Wert oder eine bestimmte Konstante,
    für primitive Datentypen sicherlich schwieriger, da gibts noch 0 oder -1, bei boolean wirds haarig
    So würd ich das in solchen Fällen dann auch lösen. Und wegen den primitiven Datentypen: Dann halt Wrapper verwenden.

  13. #13
    propra


    Oha, da habe ich ja was losgetreten...
    Vielen Dank erst einmal.

    Vielleicht machen wir es einfach etwas konkreter.
    Ich habe ein Programm geschrieben, in dem es möglich ist Knoten zu zeichnen, die durch Kanten verbunden werden können.
    Im konkreten Fall geht es nun darum, genau so eine Kante zu zeichnen. Die Methode [C]createEdge(Point p)[/C] bekommt nur die Koordinaten eines Mausklicks übergeben. Mit Hilfe dieser wird dann aus einer Liste von ausgewählten Knoten der entsprechende Knoten ausgewählt.
    Da die Methode sowohl für die Wahl des Start-, als auch Endknoten benutzt wird, habe ich die anfangs geschilderte Situation.

    Die Lösung mit [C]flipMyBoolean()[/C] finde ich sehr elegant, verständlicher wird aber sicherlich [C]enableMyBoolean()[/C] und [C]disableMyBoolean()[/C] sein.

    Was denkt Ihr?

  14. #14
    Gast2

    verwende statt [C]enable...[/C] und [C]disable...[/C] lieber
    Java Code:
    1. public void setMyBoolean(boolean myBoolean) {
    2. this.myBoolean = myBoolean;
    3. }

    Dann hast du nen gewöhnlichen setter.

  15. #15
    hdi


    Da die Methode sowohl für die Wahl des Start-, als auch Endknoten benutzt wird
    Dann sollte das vielleicht nicht so sein. Ich denk du hast da ein kleines Design-Problem, und hast bestimmte Verantwortungen im Code an der falschen Stelle. Es lässt sich sicherlich auch ganz ohne diesen boolean lösen.

  16. #16
    propra


    Zitat Zitat von EikeB Beitrag anzeigen
    verwende statt [C]enable...[/C] und [C]disable...[/C] lieber
    Java Code:
    1. public void setMyBoolean(boolean myBoolean) {
    2. this.myBoolean = myBoolean;
    3. }

    Dann hast du nen gewöhnlichen setter.
    Ok, stimmt, das ist weniger Code, der trotzdem seinen Zweck erfüllt.

    Zitat Zitat von hdi Beitrag anzeigen
    Dann sollte das vielleicht nicht so sein. Ich denk du hast da ein kleines Design-Problem, und hast bestimmte Verantwortungen im Code an der falschen Stelle. Es lässt sich sicherlich auch ganz ohne diesen boolean lösen.
    Hm..
    Bisher dachte ich eigentlich, dass es immer eine gute Idee ist, seine Methoden "so flexibel" und wiederverwendbar, wie möglich zu machen. Deshalb habe ich eine Methode geschrieben, die ich für Startknoten- und Endknotenwahl nehmen kann.
    Ist es denn besser eine Methode [C]selectStartNode()[/C] und eine [C]selectEndNode()[/C], ob wohl in beiden im Prinzip derselbe Code steht? Für mich wäre das dann redundanter Code, den es zu vermeiden gilt.

  17. #17
    hdi


    Ja wie, selber Code? Ist Start- und Endknoten nun das selbe für deine Logik oder nicht? Wenn nicht dann kann es ja nicht der selbe Code sein. Du hast irgendwo ein if() drin, oder? Zeig doch mal die Methode, bzw alles was man kennen muss um zu verstehen was die Logik dahinter ist.

  18. #18
    hdi


    Schau dir mal das hier an:

    "The Clean Code Talks -- Inheritance, Polymorphism, & Testing" - YouTube

    Stichwort Strategy Pattern. Ohne deinen Code kann ich jetzt nicht sagen ob das Overkill ist oder nicht. Aber grundsätzlich sollte man if()-Statements mit Vorsicht genießen. Primitive Prüfungen sind nicht vermeidbar und auch total okay (zB bei mathematischen Vergleichen) aber wenn die Logik abhängt von einem Objekt-Zustand oder gar der Kombination mehrerer solcher, dann ist es oft sinnvoller sowas wie eben das Strategy Pattern anzuwenden. Wenn du mir deinen Code zeigst kann ich dir konkreteres sagen, ich hab das jetzt nur mal gepostet weil ich nicht weiß ob von deiner Seite aus noch was kommt

  19. #19
    HimBromBeere


    Ein Setter (bzw allgemeine jede Methode) sollte keine unerwarteten Seiteneffekte haben.
    Was heißt hier unerwartet? Man könte natürlich auch ein Changelistener (was in dem vorliegenden Fall KEINES WEGS übertrieben ist^^auf das Objekt drausfsetzen, das ist doch auch nix anderes. Also in irgendeiner Form musst du dem System ja sagen, dass sich was verändert hat... oder seh ich das falsch?

  20. #20
    hdi


    Man könnte natürlich auch ein Changelistener auf das Objekt drausfsetzen, das ist doch auch nix anderes.
    Doch, das ist schon was anderes. Denn mit nem ChangeListener werde ich über die Änderung benachrichtigt (die Listener-Methode wird aufgerufen). Also weiß ich: Es hat sich etwas geändert, und jetzt muss ich so und so reagieren. Dahingegen wenn das einfach so im Setter verschluckt wird, dann wird keine Methode o.ä. aufgerufen. Der Code geht normal nach dem setter-Aufruf in der nächsten Zeile weiter, und ich hab nicht den blassesten Schimmer von der Änderung irgendeiner komischen Variable, die für mich mit dem Setter gar nix zu tun hat.

12
Java Videokurs

Keine Antwort auf Deine Suche gefunden? Registriere Dich kostenlos und stelle Deine eigene Frage zu Java!

Jetzt kostenlos registrieren