Klassen Prüfungen im Setter

Dieses Thema Klassen - Prüfungen im Setter im Forum "Allgemeine Java-Themen" wurde erstellt von smox, 22. Nov. 2016.

Thema: Prüfungen im Setter Hallo Leute, Ich hab da mal eine Frage an euch. Als ich mit der Java Programmierung begonnen habe, wurde mir schon...

  1. Hallo Leute,
    Ich hab da mal eine Frage an euch. Als ich mit der Java Programmierung begonnen habe, wurde mir schon brav beigebracht beim Setzen der Variablen Prüfungen vorzunehmen und die entsprechenden Exceptions zu werfen.

    Nach ein paar Monaten im Beruf ist mir aufgefallen, dass wir diese Prüfungen nicht im Setter vornehmen. Nach Rückfrage bei unserem Software-Architekt, wurde mir erklärt dass eine Prüfung im Setter anscheinend ein absolutes No-Go ist. Er meinte, dass man dafür eher einen eigenen Service Layer einziehen sollte.

    Jetzt zu meiner Frage, wie handhabt ihr das? Ist das quasi ein Designpattern ob man im Setter prüft oder ist das eher wirklich eher unsauberer Stil so wie es mir unserer Architekt erklärt hat?


    Danke und LG
    Michi
     
  2. Vielleicht hilft dir das Java-Tutorial weiter. Hier klicken --> (Klick)
  3. Kommt drauf an mMn...

    ein
    Code (Java):
    public void setAge(int age) {
       if(age > 0) {
          this.age = age;
       }
    }
     
    finde ich im setter gut aufgehoben.

    Ein
    Code (Java):
    public void setUsername(String username) {
       if(!db.usernameExists(username)) {
          this.username = username;
       }
    }
     
    gehört mMn in einen Service Layer.

    Wenn ich keine Prüfungen im Setter machen dürfte, könnte ich ja die Variable auch direkt setzen. (Vom JavaBeans Standard mal abgesehen)
     
  4. Bei der ersten Variante, wirfst du da schon eine Exception wenn das Alter nicht passt, oder?

    Ja, zweite Variante finde ich, gehört auch nicht dort hinein.
    Ich würde sowas aber sehr wohl in mein DAO schreiben, oder findest du dass das dort auch nicht hineingehört?
    Er meinte jedoch (mit geschlossener Mehrheit unter den Kollegen), dass sowas gar nicht in Setter gehört. Die sind nur dazu da, um Werte zu setzen. Das würde zumindest diese komischen Proberties in C# erklären, weil dort hab ich mich auch immer gefragt weshalb es die überhaupt gibt, wenn man dort keine Prüfungen rein schreibt.

    Das Problem ist, selbst die Meinung der Lehrer ging hier auseinander. :-/
     
  5. Joose
    Joose Mitarbeiter
    Um auf das Beispiel von thecain zurück zugreifen:

    Code (Java):
    public void setAge(int age) {
       if(age < 0) {
         throw new Exception("alter darf nicht < 0 sein!");
       }
       this.age = age;
    }
     
    Im Setter darf und sollte man auch Prüfungen einbauen, sofern diese natürlich auch sinnvoll sind.Ein Alter kann nie negativ sein, daher ist es nicht falsch im Setter zu prüfen ob sowas gesetzt werden soll.
    Natürlich ist es nicht verboten schon auf ein korrektes Alter im ServiceLayer zu prüfen, bevor überhaupt was gesetzt werden soll. Man prüft dann vielleicht doppelt, aber man muss nicht eine Exception fangen und behandeln.

    Und wenn ich keine Prüfungen einbauen dürfte, dann machen setter/getter keinen Sinn und man könnte direkten Zugriff auf die Variablen gewähren.

    Die Aussage stimmt natürlich, ist aber eben unvollständig. Setter sind auch dazu da um ungültige Werte "abzufangen".

    Beispiel: Du hast eine Klasse Person in einer Bibliothek und willst diese in mehreren anderen Projekten verwenden. In jedem dieser Projekte müsstest du dann die Prüfung auf das Alter einbauen und warten! Baust du die Prüfung hingegen im setter ein erledigt sich dieses Problem "von alleine".

    Es gibt eben auch Attribute bei denen ist es egal welcher Wert gesetzt wird (sprich keine Prüfungen gebraucht werden).
    Außerdem sind diese "komischen Properties" in C# nur Syntaxzucker ;) ... beim Compileren werden daraus normale getter/setter (soweit ich informiert bin)
     
  6. Dann Danke erstmal für die Antworten.
    So hab ichs eigentlich auch gelernt. Ich war nur erschocken, dass es anscheinend jeder anders sieht als ich.
    Ist euch im beruflichen Umfeld schon was ähnliches passiert?

    LG
    Michi
     
  7. Welchen Sinn hat denn Datenkapselung? Unter anderem natürlich nur gültige Werte und somit einen validen Zustand zu ermöglichen. Und falsche Zustände zu verhindern.

    Man kann höchstens getter+setter anzweifeln. Denn die sind ja eine Java-Beans-Spezialität, die erstmal mit OOD wenig zu tun hat. Wenn ich bei einer Klasse Fahrzeug die Methode nicht z.B. setGeschwindigkeit(int) sondern beschleunigeAuf(int) nenne... ist dann eine Prüfung in beschleunigeAuf erlaubt? Darf ich auf 1000 kmh beschleunigen? Oder ist dort eine Prüfung drin?
    Es wird bestimmt eine Prüfung stattfinden! Warum? Weil die Datenkapselung verhindern soll, das unsinnige Werte rein kommen. Wie man nur wegen einer Java-Bean-Spec das nicht mehr machen darf, ist mir schleierhaft.

    Übrigens, bei uns auf Arbeit sind in den Settern, wenn sinnvoll, natürlich Prüfungen erlaubt.
     
    Joose, sascha-sphw und JStein52 gefällt das.
  8. Du müsstest unterscheiden zwischen "speicherbaren" und "logischen" Daten.
    Der Setter liegt eine Stufe über dem tatsächlichen Dateninhalt, sollte nicht viel mehr machen als zu prüfen, ob die Daten rein datentechnisch in Ordnung sind, bzw. notwendige Konvertierungen vornehmen. Ob die Daten sinnvoll sind oder nicht, hängt starkt von ihrer Anwendung ab, sollte also schon vorher geprüft worden sein.
    Der Setter kümmert sich auch um PropertyChange-Events usw, hat also durchaus seine Existenzberechtigung (auch in anderen Sprachen, nicht nur Java)
     
  9. Schau dir jetzt hier den Kurs an und lernen Java zu programmieren: --> Hier klicken, um mehr zu erfahren (Klick)