Klasse zu groß (>3000 codezeilen). wie sinnvoll strukturi

Status
Nicht offen für weitere Antworten.

gondor

Bekanntes Mitglied
hallo!

ich habe eine frage bezüglich großer klassen. ich habe ein Klasse myApplikation, welches ein frame darstellt. auf diesem frame sind viele viele button, textfelder, combo-boxen, etc... jedes dieser komponenten besitzt einen listener, die wenn ein event geschieht einen adapter aufrufen und das event weitergeben an die dafür vorgesehende methode:
Code:
class General_jTextField_LogSize_keyAdapter extends java.awt.event.KeyAdapter {
    
myApplikation_Gui_Frame_Preferences adaptee;

    General_jTextField_LogSize_keyAdapter(myApplikation adaptee) {
        this.adaptee = adaptee;
    }

    public void keyPressed(KeyEvent e) {
        adaptee.General_jTextField_LogSize_keyPressed(e);
    }
}
Code:
void General_jTextField_LogSize_keyPressed(KeyEvent e) {
        General_jButton_Accept.setEnabled(true);
        General_jLabel_StatusMessage.setText("Press 'Accept-Button' to save Modifications");
}
dabei entsteht code... viel code. alleine die instanzen der swing-elemente und deren 'behandlung' brauchen schon allein >300 zeilen. kommen jetzt die ganzen adapter-klassen und die event-methoden dazu komme ich schnell auf bis zu 2000 zeilen. das ist mir eindeutig zu viel. da verliert man ja komplett die übersicht 😉 sollte bestimmt auch nicht so gemacht werden, oder?

wie kann man das geschickt umgehen? hat jemand einen tipp?

kann man die evtl. geschickt 'kapseln' oder in einer anderen klasse setzen? was ist hier sinnvoll?

danke für hilfe,

gondor(..)
 
Also wenn der Code zu lang ist, dann wuerde ich immer versuchen das ganze in mehrere Klassen und Methoden aufzuteilen. Das mach das ganze dann auch viel uebersichtlicher...

Du musst mal sehen, an welchen Stellen das Sinn macht - ist nicht so einfach - weiss ich... C'est la vie!
 
deswegen ja meine frage ???:L macht das sinn, die event-behandlung in eine andere klasse zu behandeln?

bambi hat gesagt.:
Also wenn der Code zu lang ist, dann wuerde ich immer versuchen das ganze in mehrere Klassen und Methoden aufzuteilen. Das mach das ganze dann auch viel uebersichtlicher...

Du musst mal sehen, an welchen Stellen das Sinn macht - ist nicht so einfach - weiss ich... C'est la vie!

gondor(..)
 
gondor hat gesagt.:
... dabei entsteht code... viel code. alleine die instanzen der swing-elemente und deren 'behandlung' brauchen schon allein >300 zeilen. kommen jetzt die ganzen adapter-klassen und die event-methoden dazu komme ich schnell auf bis zu 2000 zeilen. das ist mir eindeutig zu viel. da verliert man ja komplett die übersicht 😉 ...
Ich hab ja keine Ahnung was Du da machst. Evtl. wäre das ein Thema: "Komponenten Dynamisch erzeugen"?

Solltest Du mit C++ befreundet sein, dann empfehle ich Dir mal dieses Beispiel zu studieren: Auf www.cbuilder.de unter Source Code gibt es ein Topic welches auf "Komponenten Dynamisch erzeugen" hört. Ein Javabeispiel kenne ich dafür nicht.
 
ich würde mal alle listener "outsourcen" 🙂

schau dir sonst einmal ein paar open source swing anwendungen an, wie sie ihre klassen aufteilen.
 
@roar

hm... komm damit auch nicht viel weiter 🙁

kann mir man das auch mit code zeigen? es geht mir nicht nur um die 'aufteilung', sondern auch wie es vom 'code' her gemacht wurde...
 
Ich mache das immer (wenn es viele GUI-Elemente sind) so, dass ich eine GUI-Klasse habe und einen zugehörigen 'GUI-Controller', welcher die benötigten Listener-Interfaces Implementiert:

Du kannst Dir das so vorstellen:

Code:
public class GUI {
//...
GuiController guic = ...;
//...
JButton button1 = new JButton();
button1.setActionCommand("button1_click"); 
button1.addActionListener( guic );
//...
}

Code:
public class GuiController implements ...{
//...
public void actionPerformed(ActionEvent e)  {

  if ( "button1_click".equals(e.getActionCommand()) {
    //...
  }
}
//...
}

Das muss man natürlich ein bißchen 'zu Fuss' proggen... der gute alte JBuilder nimmt einem das nicht ab...
 
Status
Nicht offen für weitere Antworten.

Neue Themen


Zurück
Oben