Guter Programmierstil?

[Guest]

Hallo,

ich programmiere jetzt schon einige Zeit in Java aber bei folgendem Problem weiß ich bis heute nicht, ob das so wie ich das mache, ein guter Programmierstil ist.

Angenommen man hat eine GUI mit verschiedenen Komponenten drauf. Daneben hat man mehrere andere Klassen, die ab und zu auf GUI-Elemente zugreifen müssen (beispielsweise um die Anzahl der Spalten einer JTable zu erfahren).


Doch wie sollen die anderen Klassen am besten auf GUI Elemente zugreifen?
Mit getter und setter Methoden und zuvor den anderen Klassen das GUI Objekt im Konstruktor übergeben? Oder gibts andere Möglichkeiten?

Hier mal ein simples Beispiel:

public class TestGUI extends JFrame{
	JTable table;
	DefaultTableModel model;
	JScrollPane scroll;
	public PacketMonitor(){
		this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		
		// init gui
		String[] titles = new String[]{ "A", "B", "C"}; 
		model = new DefaultTableModel( titles, 0 ); 
		
		table = new JTable( model );
		scroll = new JScrollPane(table);
		scroll.setAutoscrolls(true);
		this.getContentPane().setLayout(new BorderLayout());
		this.add(scroll,BorderLayout.CENTER);
		this.pack();
		this.setSize(800, 600);
		this.setVisible(true);
	}
	
	
	
	public static void main(String[] args) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {          
                TestGUI gui = new TestGUI ();                
            }
        });
	}



	public DefaultTableModel getModel() {
		return model;
	}	

	public void setModel(DefaultTableModel model) {
		this.model = model;
	}
	
	public JTable getTable() {
		return table;
	}
	
	public void setTable(JTable table) {
		this.table = table;
	}

	public JScrollPane getScroll() {
		return scroll;
	}

	public void setScroll(JScrollPane scroll) {
		this.scroll = scroll;
	}

}

Einer anderen Klasse hab gebe ich das GUI Objekt im Konstruktor und nutze dann die setter und getter Methoden. Aber ist das so richtig bzw. guter Programmierstil?

 

[Marco13]

Ist ein bißchen wenig Information. Im allgemeinen sollten die "Kernklassen" (also der Teil, der die Programmlogik enthält) NICHT aufs GUI zurückgreifen. Wenn die "anderen Klassen" auch GUI-Klassen sind, mag das OK sein. Wenn es Logik-Klassen sind, sollten sie bestenfalls das TableModel kennen (aber auch da muss man sich genau überlegen, ob man diese Information nicht in einem eigenen Datenmodell speichert). Stell dir (zur Verdeutlichung) vor, dass dein Programm auch laufen können sollte, OHNE dass ein GUI existiert. Bei sowas wie getTable().getNumRows() wäre das evtl. nicht möglich.

 

[Pappenheimer++]

IMHO wär es besser, eine Controller-Klasse anzulegen. Die macht das ganze dann übersichtlicher, wartbarer, sauberer und du kannst die üblichen Thread-Probleme (race cond. , deadlocks) leichter in den Griff kriegen als wenn du verschiedene im Hintergrund arbeitende Threads hast, die hin und wieder "wild" die GUI updaten.

 

[Gast]

Hm,

also striktes MVC Konzept.
Besteht der Controller dann aus "static" Methoden? Denn irgendwo muss ich ja die Model-Klassen und GUI-Klassen speichern? Wenn der Controller nicht statisch ist, dann muss ich ja dauernd das Controller-Objekt mit herumschleppen.

 

[SnooP]

Eigentlich ist es der Controller, der die anderen Objekte mit sich herum schleppt... - weder View noch Modelobjekte sind dann direkt mit der "Anwendung" verbunden - bzw. die Anwendung ist eine lose Kopplung aus Controllern, die alles steuern...

und... nein - nicht static - nein! nein... neinneinnein... - nein!