[quote=Marco13]Vielleicht soll dort irgendeine Prüfung stattfinden (nicht-null, String nicht leer…)[/quote]Ich sehe keinen Grund, diese Prüfung nicht im Konstruktor zu machen.
IMHO sollte es nicht möglich sein, ein Objekt mit ungültiger Konfiguration erstellen zu können.
bye
TT
Aber wenn man verschiedene Konstruktoren (andere Parameter) hat, sollte die Prüfung eines Parameters, dass bei allen vorkommt gleich sein und nicht 5 mal kopiert werden., weshalb dann eine Methode durchaus Sinn macht.
[quote=cresse]sollte die Prüfung eines Parameters, dass bei allen vorkommt gleich sein und nicht 5 mal kopiert werden., weshalb dann eine Methode durchaus Sinn macht.[/quote]Eine Prüf-Methode: Ja.
Ein Setter: nein.
bye
TT
Ich bin schon davon ausgegangen, dass der Konstruktor nicht die einzige Stelle ist, wo der Setter verwendet wird. Aber das sind vielleicht Kleinigkeiten.
Hab gerade mal mit Netbeans probiert. Es meckert, wenn man öffentliche Methoden im Konstruktor positioniert. Es meint, dass diese überschrieben werden können…
Ja, die Setter sollten dann ggf. final sein (das sollte bei NetBeans die Warnung beseitigen). Ansonsten kann es bei bestimmten Konstrukten ziemlich schwer werden, einen konsistenten Zustand sicherzustellen…
Reicht es nicht, dass die zu setzende Eigenschaft private ist? Dann kann man die Methode doch überschreiben wie man will, an die zu setzende Eigenschaft kommt man höchstens noch über JNI oder Reflections. Ob das ganze dann in der Erweiterten Klasse noch konsistent ist, ist doch dann Sache des Entwicklers der Erweiterung. Dieser müsste ohnehin auch den Getter überschreiben und wenn ich diesen in der Klasse selber auch verwende, bleibts auch konsistent (vermute ich mal).
Das genau ist doch das Problem. Wenn Methoden bei der Initialisierung verwendet werden, sollten diese final oder private sein. PMD bzw. Checkstyle sollten einen auch darauf hinweisen. Alles was überschrieben werden kann, kann die Instanz in einen ungültigen Zustand bringen. sofern im Konstruktor aufgerufen.
Ich bleibe dabei: private Felder direkt im Konstruktor setzen. Wenn Methoden erforderlich sind, dann sollten diese final bzw. private sein (wobei final Methoden häufig gefährlich sind).
…weil… ??? Ich versuche i.A. die eindeutigen Modifier zu verwenden, grob im Sinne von ClarityOfAccessModifiers - APIDesign - und da kommt „final“ recht oft vor. (Ich weiß, es kann nerven, wenn man eine API so zunagelt, aber… es hat schon seine Gründe…)
Die Proxy-Generierung von final-Methoden ist problematisch. Da haben viele Generatoren (z.B. Seam 2.x) Probleme.
Ich persönlich nutze final so oft es geht. Aber man muss sich dann bewusst sein, wo es bei Methodendeklarationen zu Problemen kommen kann.