Lange Methodenaufrufe == suboptimales Klassendesign?

[Maik.Neumann]

Hallo !

Ich habe mal eine Frage an euch. Manchmal passiert es mir, dass ich in meinem Sourcecode Methodenaufrufe, wie den folgenden implementieren muss:

public void getAnzahlPersonen(final FormModel formModel){

    return formModel.getService().getPersonenDao().getAnzahlPersonenProQuartal();

}

Das ist jetzt natürlich ein sehr abstraktes Beispiel (teilweise auch von mir stark vereinfacht und deutlich modifiziert). Was ich hier verdeutlichen will, sind die vielen mit dem . gtrennten Methodenaufrufe.

Ich finde diese generell merkwürdig (häufig aber unvermeidbar), teilweise auch schlecht lesbar und frage mich deshalb, ob sie schon eine Art Bad Smell darstellen könnten?

Wie seht ihr das? Deuten solche Aufrufe schon ein ein fehlgeschlagenes Klassendesign und falsche-, oder gar keine Trennung von Zuständigkeiten innerhalb der Klassen hin? Weiß eine Klasse evtl. zuviel und die andere zu wenig?

Gibt es für solche Art von Methodenaufrufen eigentlich auch eine offiziell anerkannte Bezeichnung?

Danke und Gruß

 

[djafix]

also ich würde vorschlagen getAnzahlPersonenProQuartal() schon in der klasse von formModel zu implementieren. also einfach die methoden dort durchgeben, dass du dir schon von der obersten klasse in der hierarchie den wert geben lassen kannst.
aber ob das nun guter oder schlechter stil ist, muss glaub ich jeder für sich selbst wissen. einfacher wäre es in jedem falle so zu machen wie oben beschrieben

 

[Joose]

Ja solche Verkettungen von Methodenaufrufen sind schlecht!
Unter anderem hast du den Nachteil, eine dieser Methoden "null" zurückliefert und dabei dann eine Exception geworfen wird. Sprich dir fehlt eine Prüfung ob du überhaupt einen entsprechenden Service oder DAO zur Verfügung hast.
Außerdem ist so keine Trennung deiner Schichten möglich (bzw. schwerer) weil formModel deine Services kennen muss, deine Daos usw..

Also wie djafix schon sagt ... die einzelnen Aufrufe einfach in den enstprechenden Klassen kapseln! So kannst du eine entsprechende Fehlerbehandlung implementieren und auch dein Programm schön trennen (GUI <-> Logik <-> Daten)

 

[Maik.Neumann]

Hallo !

Also wie djafix schon sagt ... die einzelnen Aufrufe einfach in den enstprechenden Klassen kapseln!

Ich verstehe nicht ganz, wie das konkret aussehen soll, dass einzelne Aufrufe in entsprechenden Klassen gekapselt werden sollen. Führt das letztenendes nicht wieder darauf zurück, dass mein FormMOdel alles kennen muss? Irgendwie habe ich da ein Verständnisproblem

 

[djafix]

du kannst einfach eine methode in der klasse FormModel namens getAnzahlPersonenProQuartal() definieren in der einfach formModel.getService().getPersonenDao().getAnzahlPersonenProQuartal() zurückgegeben wird.

besser wäre aber, wie joose beschrieben hat, das über jede klasse zu machen:

1. in PersonenDao eine methode namens getAnzahlPersonenProQuartal()
2. in Service eine Methode getAnzahlPersonenProQuartal() welche methiode unter 1. aufruft
3. Methode in FormModel namens getAnzahlPersonenProQuartal(), welche methode unter 2. aufruft

damit ist aufjedenfall das problem mit dem langen namen gelöst. und wenn deine klassen es halt nicht anders zulassen, dann muss das formModel nunmal alle seine klassen kennen

 

[Natac]

Zu einem gewissen Grad gebe ich meinen Vorpostern Recht.

Ich halte es bei mir so, dass ich bspw. in der Gui ein zentrales Objekt (Nennen wir es "Logic") habe, über die für die jeweilgen Daten Operationen aufrufbar sind. Wenn ich jetzt aus einem Dialog allerdings prüfen will, ob der Namen eines Nutzers existiert kann es schonmal eine Aufrufkette geben, in der ich mich erst zum zentralen Objekt hin-"hangele" und dann die Abfrage mache:

public UserDialog extends JDialog{

private boolean userExists(String name){ // von irgendwo im Dialog aufgerufen
 return getMainFrame().getLogic().getUserManager().existsByName(name);
}
}

Hierbei kann ich aber sicherstellen, dass keine Aufruf null zurückliefert. Sicherlich könnte man darüber streiten, ob der UserDialog nicht eine Methode getUserManager haben sollte, die man aufruft und dann einfach den ersten Teil kapselt. Ich für meinen Teil spare mir diese privaten Methoden aber lieber und schreibe obige Ketten, da ich die Zusatzmethoden (zumal die dann evtl. nur einmal genutzt werden) den Code unleserlicher machen als die obige Kette.

Prinzipiell solltest du dich fragen, ob du mit so einer Kette deinen Scope verlässt (bspw. direkte Navigation von der Gui in die Persistenzschicht), oder eben nicht. In ersterem Fall würde ich von der Aufrufkette auch eher abraten, da du damit die Kapselung verwischt. Im zweiten Fall finde ich das eher weniger problematisch.