Hallo, ich habe gerade ein privates Projekt und möchte nun mal anfangen den ganzen Code ein wenig zu verschönern. Dabei kommen bei mir folgende Fragen auf:
1.ActionListener
Ich habe so 10-20 Actions. Soll ich jedem Button einen neuen ActionListener hinzufügen(sehr Zeilen intensiv und irgendwann auch nicht mehr wirklich leserlich), soll ich über den ActionCommand gehen und damit dann ActionListener per implements bereitstellen (riesige actionPerformed Methode), anonyme Klasse… was ist hier der beste weg, um das leserlich zu gestalten.
2.Modell-Klassen
Ich habe zwei Klassen RowObject und ResultObject. ResultObject hat die gleichen Attribute und getter&setter wie RowObject, nur RowObject hat noch ein paar mehr Attribute. Soll ich eine Superklasse erstellen von der beide erben und bei RowObject dann diese Klasse einfach um die anderen Attribute erweitern ? Oder einfach direkt nur noch RowObject nehmen und die restlichen Attribute dann einfach null lassen…
3.GUI-Panel-Methoden
Meine Panel sind mitunter ein wenig aufwändig. Sollte ich eine neue Klasse für jeden Panel erstellen und diese Klasse dann von JPanel erben lassen, oder ganz normal in einer Methode den Panel erstellen und diese Methode dann im Konstruktor/main-Methode aufrufen. Ich habe halt ca 7-8 von solchen Methoden wo Panels erstellt werden und diese Methoden werden auch ganz schön lang was das ganze ziemlich unübersichtlich macht.
4.Ist Composition over Inheritance wirklich etwas was man immer beherzigen sollte ? Im Moment habe ich noch ein extends JFrame bei mir in der Klasse stehen, was wäre der Vorteil dies zu ändern ?
Gibt es noch weitere Patterns, Modelle die ich mir bei der Umstrukturierung zu Herzen nehmen sollte ?
Danke für alle Antworten, egal welchen Punkt betreffend
[QUOTE=dehlen]1.ActionListener
Ich habe so 10-20 Actions. Soll ich jedem Button einen neuen ActionListener hinzufügen(sehr Zeilen intensiv und irgendwann auch nicht mehr wirklich leserlich), soll ich über den ActionCommand gehen und damit dann ActionListener per implements bereitstellen (riesige actionPerformed Methode), anonyme Klasse… was ist hier der beste weg, um das leserlich zu gestalten.[/QUOTE]
Das mit dem ActionListener per implements und der riesigen actionPerformed-Methode ist wohl die schlechteste Idee. Wenn, dann eher zu jedem Button einen anonymen ActionListener hinzufügen und eine eigene Methode aufrufen. Oder mit Actions (jeder Button bekommt eine Action-Klasse zugewiesen) arbeiten.
Wenn du keine Methode von JFrame überschreibst: Ruhig raus damit.
Änderungen innerhalb der Klasse: sowas wie add() oder this.add() wird zu frame.add().
Änderungen außerhalb der Klasse: Kein direkter Zugriff mehr auf das Frame (bessere Kapselung), Man kann auf deiner Klasse ~150 Methoden weniger aufrufen, die man eh niemals verwendet.
[quote=dehlen;73982]2.Modell-Klassen
Ich habe zwei Klassen RowObject und ResultObject. ResultObject hat die gleichen Attribute und getter&setter wie RowObject, nur RowObject hat noch ein paar mehr Attribute. Soll ich eine Superklasse erstellen von der beide erben und bei RowObject dann diese Klasse einfach um die anderen Attribute erweitern ? Oder einfach direkt nur noch RowObject nehmen und die restlichen Attribute dann einfach null lassen…[/quote]
Macht es Sinn, die identischen Attribute aus RowObject herauszuwerfen und durch eine Composition mit ResultObject zu ersetzen?
Je nach Kontext kann es auch besser sein, wenn die Klassen unterschiedliche Namen haben.
Falls du häufig Fälle hast, in denen dein Result ein RowObject ist, bietet sich Vererbung an (Spezialisierung).
Ok danke euch schonmal. Die ActionListener und den JFrame hab ich angepasst. Das mit RowObject und ResultObject werde ich wohl so lassen wie es ist, weil es sinnvoller ist das als getrennte Klassen zu betrachten.
3.GUI-Panel-Methoden
Meine Panel sind mitunter ein wenig aufwändig. Sollte ich eine neue Klasse für jeden Panel erstellen und diese Klasse dann von JPanel erben lassen, oder ganz normal in einer Methode den Panel erstellen und diese Methode dann im Konstruktor/main-Methode aufrufen. Ich habe halt ca 7-8 von solchen Methoden wo Panels erstellt werden und diese Methoden werden auch ganz schön lang was das ganze ziemlich unübersichtlich macht.
Würde ich auf jeden fall machen. Wenn du da unbedingt Composition über Inheritance leben willst, mach dir eine Factory Klasse mit einer createXXXPanel Methode für deine Panels. Ich finds aber schöner und zweckmäßiger für diese GUI-Komponenten eigene Klassen zu machen, meistens braucht man ja dann auch noch set/get Methoden die irgendwelche Formularfelder bedienen.
Ok danke dir. Das gehe ich dann morgen an. Habe auch die ein oder andere Redundanz durch Methoden beheben können. Ich denke wenn ich die Panel noch auslagere ist der Code ein ganzes Stück leserlicher geworden.
