Designfrage/Objektorientierung

[GhostfaceChilla]

Hallo Leute

Da ich das Buch Java ist auch eine Insel demnächst soweit durch habe, hab ich mir ein Projekt überlegt. Und zwar möchte ich einen Terminkalender erstellen, welcher auch eine GUI besitzt. Nur hab ich dazu ein paar fragen.
Die GUI stell ich mir wie folgt vor:
Oben sollte eine Menüleiste sein, bis jetzt nur mit Datei wo man dann speichern kann einen neue Kalender anlegt oder einen neuen Terming.Dann ist ca. 2/3 des Bildschirms dafür da z.B den Titel des Termins zu bearbeiten, Startuhrzeit, Enduhrzeit Beschreibung und noch Platz für eine Notiz. Das andere 1/3 zeigt dann einen Teil des Kalenders an.
Jetzt zu meiner eigentlichen Frage. Wie fange ich an?Also geh ich hin und packe die gesamte GUI in eine Klasse oder eine extra Klasse für jeden Abschnitt, also für die Menüleiste das Bearbeitungsmenü und den Kalender oder doch eher nicht?

Außerdem stellt sich mir die Frage ab wann man eigentlich eine Klasse erstellt also ab wann es wirklich von nöten ist eine zu erstellen, will am Ende nämlich nicht 20 unnötige Klassen haben. Habt ihr vllt. weiter Tips und Tricks wie man am Besten so ein Projekt angeht?Habe zwar schon kleine Programme geschrieben aber noch nie etwas komplexeres deswegen bin ich zur Zeit ein bisschen hilflos, da ich noch keine richtigen Erfahrungen in der OOP habe

Vielen dank schonmal

-GhostfaceChilla-

 

[wolfgang63]

Hi,
die selben Probleme habe ich auch immer. Wenn man die Onlinetutorials ansieht wird meist immer alles in ein oder zwei Klassen gepackt. Dabei steht doch in jedem Javabuch das man die Aufgaben weitesgehend splitten soll.
Ich würde auf jeden Fall die Gui und die Logik in separate Klassen legen. Da kommt halt der Mehraufwand mit der Datenübergabe hinzu. Aber das ist halt so bei OOP. Bei größeren Projekten verliert man sonst den Überblick und es schleichen sich Fehler ein weil unbeabsichtigt Variableninhalte verändert werden.
Viele Grüße...

 

[Admiral Helmut]

hallo,

ich denke ein wichtiges prinzip für den Anfang ist die "Eine Verantwortlichkeit", das heisst jede Klasse hat genau eine Aufgabe.
Gui kannst du denk ich in eine Klasse packen.
Zeichne dir einfach mal auf einen Block ein Klassendiagramm mit experimentiere ein bisschen rum.
bis du denkst der Entwurf ist gut, hat ne schöne Aufteilung, ist gut zu implementieren und du hast keine unnötigen redundanten Daten.


gruß

 

[GhostfaceChilla]

Viel Dank shconmal euch 2
Noch jemand ne Idee?Wäre es auch ok wenn ich die Logik der GUI und die GUI an sich in eine Klasse mache?

-GhostfaceChilla-

 

[rme]

Hallo

Ich mache das immer folgendermaßen:

* es gibt für jedes GUI-Fenster (das viele Komponenten beinhalten kann) eine Controller-Klasse

* der Controller erzeugt im Konstruktor sein Fenster, d.h. ungefähr so:

public class MainController {
  private MainGUI gui;
  public MainController() {
    this.gui = new MainGUI(this); // MainGUI extends JFrame
  }
}

Die GUI-Klassen kennen also ihren Controller. Der Grund ist, dass sie dann alle Events an den Controller weiterleiten können - jede Aktion in der GUI (Klick auf Button usw.) wird von einem ActionListener in der GUI behandelt, der aber einfach ohne weitere Prüfung das Ereignis an den Controller weiterreicht, d.h. der Controller hat beispielsweise eine Methode onNameChangeRequest(), die aufgerufen wird, wenn in der GUI ein Button zum Ändern des Namens angeklickt wurde. Der Controller kann dann Dinge prüfen und der GUI sagen, was sie machen soll:

public void onNameChangeRequest() {
  String requestedName = gui.getName(); // liefert in der GUI den Text der Name-Text-Field-Komponente
  if(isNameOK(requestedName)) {
    gui.nameChanged(requestedName);
  } else {
    gui.showError("Der Name wurde aus Gründen abgelehnt.");
  }
}

Nach diesem Muster kann man den ganzen GUI-Kram (Komponenten, Listener etc.) schön von der eigentlichen Logik trennen, der Controller wird also schön einfach zu lesen und zu pflegen. Der Controller sollte deshalb auch nicht auf die einzelnen Komponenten eines Fensters direkt zugreifen, also es sollte keine Getter für die Komponenten geben, über die der Controller dann arbeitet - denn dann müsste er wieder GUI-Code haben. Stattdessen sollen die GUI-Klassen Methoden bereitstellen, die dann die entsprechenden Elemente ändern. Das hat den Vorteil, dass man eine Komponente durch eine ganz andere ersetzen kann und dann nur die Methode der GUI angepasst werden muss - für den Controller bleibt alles gleich, weil er über diese Adapter-Methode mit der GUI spricht.

Ganz sauber wäre es dann, wenn der Controller die GUI nicht mit allen Methoden (sie erbt ja von JFrame oder so), sondern nur über ein interface:

private MainGUI gui; // MainGUI ist ein interface
...
public class MainGUIImpl implements MainGUI {
...
}

Auf diese Weise sorgt man dafür, dass der Controller sauber bleibt - er kann gar nicht auf Swing-Kram zugreifen, weil keine solche Methode im Interface vorhanden ist.

Die Daten sollten von der GUI und vom Controller auf die gleiche Weise getrennt werden. Die GUI macht also wirklich nix, als Dinge auf Nachfrage des Controllers anzuzeigen und Events über saubere Methoden an den Controller zu melden. Der Controller verändert dann die Daten (liegen als Instanzvariablen oder so vor) und löst aus, dass sie sich in der GUI ändern.

Dieses Vorgehen ist als Model-View-Presenter bekannt und gilt als die sauberste Lösung. Die strikte Anwendung ist jedoch recht nervig, weil jede Änderung an den Daten dann erstmal über den Controller gehen muss. Eine weichere Variante ist Model-View-Controller: Der Unterschied ist dabei, dass die GUI-Klassen (die in diesen Sichtweisen als Views bezeichnet werden) sich als Observer auf den Daten (die hier Models heißen) anmeldet, sodass es nicht über den Controller laufen muss. Der Ablauf ist dann, dass der Controller von der GUI über eine Änderung informiert wird, diese Änderung der Daten-Klasse mitteilt - und die GUI als Observer automatisch davon erfährt und sich aktualisiert.

Vielleicht ist eines dieser Muster ja interessant für dich

 

[GhostfaceChilla]

Vielen Dank
Hast mir schonmal sehr geholfen.
Ja sowas in der Art hab ich auch eben gerade gefunden im Internet. Also würde ne Große Klasse GUI erstellen davon dann die GUI für einen Login und für die Software ableiten. Jet hab ich nur noch ne Frage:
Soll ich dann für verschiedene Abschnitte in meinem Programm Klassen erstellen?Also hätte mir das so vorgestellt:
Einmal die View,Model und Controller Klasse für den Login.
So aber jetzt bei meiner 'Haupt'software hätte ich dann untergliedert zwischen:
-View,Model,Controller Klasse für Menübar
-View,Model,Controller Klasse für das Bearbeitungsmenü
-View,Model,Controller für die anzeige des Kalenders

Also jeweils eine extra Klasse für die jeweilige View,Model und Controller.
Um sich vorzustellen warum ich es so gleidern würde:


So denke ich hätte ich alles recht übersichtlich. Oder sollte ich doch noch weiter verzweigen?

-GhostfaceChilla-

 

[rme]

Warum möchtest du eine große GUI-Klasse machen und andere davon ableiten? Die verschiedenen GUIs haben ja eigentlich keine Gemeinsamkeiten - die Login-GUI kümmert sich um Logins, die Kalender-GUI um die Anzeige der Daten. Ich sehe da keine gemeinsam benötigte Funktionialität, die nicht durch die Swing-Klassen abgedeckt wird, wenn du ganz normal von JFrame ableitest.

Du hast glaube ich den Teil mit dem View etwas falsch verstanden - wenn du für so einfache Sachen wie einen Login-Dialog oder eine Menü-Bar einen eigenen Controller und ein eigenes Model entwirfst, wirst du irgendwann wahnsinnig und verlierst die Lust am Projekt, weil das extrem aufwändig - und deshalb auch übertrieben wäre.

Ein View ist bei mir eine große Komponente, die aus vielen kleineren bestehen kann - also das ganze Hauptfenster inklusive der Menübar usw. wäre bei mir alles *eine* View-Instanz. Wenn ich dein Projekt richtig einschätze, reicht ein Controller insgesamt aus. Du hast ja nur ein Fenster, über das alles läuft. Eine Aufteilung lohnt sich erst, wenn einzelne Komponenten der GUI so mächtig sind, dass es eine Zerteilung rechtfertigt. Dein Controller greift allerdings auf mehrere Models zu: Benutzer (da du einen Login hast, gibt es wohl verschiedene Benutzer), Kalender, Termin.. das sind alles Models, die jeweils eine eigene Klasse bekommen.

Der Ablauf könnte später beispielsweise so sein:

* der Benutzer klickt auf "Neuen Termin anlegen"
* die GUI erfährt das über einen ActionListener oder ähnliches und teilt es dem Controller mit
* der Controller sagt der GUI, dass sie den Dialog für einen neuen Termin anzeigen soll und übergibt ihr ein Model, das mit den Daten gefüllt wird
* der Benutzer füllt den Dialog aus und klickt auf Ok
* die GUI gibt dem Controller das ausgefüllte Termin-Model zurück
* der Controller überprüft das Termin-Model und sagt der GUI ggf., dass es Fehler gab
* der Controller trägt das Termin-Model in das Kalender-Model des Benutzer-Models ein
* die GUI erfährt als Observer des Kalender-Models, dass es einen neuen Termin gibt und zeigt ihn an

 

[GhostfaceChilla]

Also habe ich das richtig verstanden:
Ich sollte eine GUI aufbauen in der alles enthalten ist, also Login und die komplette Hauptanwendung. Dann einen Controller erstellen der sozusagen für alle Komponenten da ist, also Login etc. und wie sieht das mit dem Model aus?Hier würde sich doch anbieten alles einbisschen aufzuteilen oder?Also wirklich zu sagen Login bekommt ein eigenes Model, Bearbeitungsmenü und der Kalender oder?

-GhostfaceChilla-

 

[rme]

Ja, das klingt schon ganz gut. Falls der Login ein eigener Dialog ist, der der eigentlichen Anwendung vorangestellt ist, hat dieser in der GUI-Klasse nix zu suchen, sondern bekommt eine eigene GUI-Klasse. Die kann der Controller dann als erstes aufrufen und später zur anderen wechseln.

Das Model für den Login ist vermutlich eher "User", dann kannst du das sowohl zum Prüfen des Logins als auch später bei der Zuweisung eines Kalenders zu einem Benutzer verwenden.

Die GUI-Klasse der Hauptanwendung sollte trotzdem in mehrere kleine Klassen unterteilt werden. Eine Komponente zum Anzeigen des Kalenders, eine für den Dialog zum Hinzufügen eines neuen Termins.. nur aus Sicht des Controllers ist das eben eine Klasse, die alles kann - dass sie selbst das an kleinere Teilklassen delegiert, soll den Controller nicht interessieren.

 

[GhostfaceChilla]

Ok dann schonmal vielen Dank
Also dann werde ich eine eigene Klasse GUI_Login machen da sie der Hauptranwendung vorangestellt wird. Dann werde ich mich an ein Konzept der Huaptanwendung machen, ich poste hier dann mal wieder wenn ich soweit weis wie alles funktionieren soll.
Und nochmals danke für die Hilfe

-GhostfaceChilla-

 

[GhostfaceChilla]

So, beim aufschreiben diverser Konzepte haben sich mir ein paar Fragen aufgetan. Z.B wenn ich im Login Benutzername und Passwort eingebe habe ich mir gedacht das erst wenn ich den login-Button drücke sozusagen der Benutzername und das Passwort abgefragt werden. Jedoch geht dies ja nicht so einfach denn dann müsste ja Benutzername und Passwort also public in der GUI gekennzeichnet werden was ja nicht Sinn und zweck vom MVC-Pattern ist oder sehe ich das Falsch? Eine andere Lösung wäre jedes mal wenn ein Buchstabe eingegeben wird das ein String zeichenweise damit gefüttert wird.Ich komm nicht ganz durch

-GhostfaceChilla-

 

[rme]

Wenn der Benutzer auf OK klickt, ruft die GUI im zuständigen Controller eine Methode authenticate auf, die den eingegebenen Namen und das eingegebene Passwort als Parameter bekommt. Dann fragt er die Model-Klasse, ob es so einen Benutzer gibt und das Passwort korrekt ist. Wenn ja, speichert er sich den aktuellen Benutzer als Instanzvariable.

Da ist also kein Bedarf, irgendeine Variable public zu haben

 

[GhostfaceChilla]

Aha ok,jetzt hab ich das mit Controller mal verstanden.
So jetzt hab ich soweit mal alles kapiert.
Vielen Dank

-GhostfaceChilla-

 

[GhostfaceChilla]

Also hätte das jetzt so gedacht:

Das wäre die Funktion in der GUI:

public UserID authenticate(){
		UserID userID = new UserID();
		userID.setUsername(usernameFromUser.getText());
		userID.setPassword(passwordFromUser.getText());
		
		return userID;
	}

Das ist die Klasse UserID(ist noch nicht ausgebaut,dient nur Testzwecken):

package standard;

public class UserID {

	private String username;
	private String password;
	
	public String getUsername(){
		return username;
	}
	
	public String getPassword(){
		return password;
	}
	
	public void setUsername(String username){
		this.username = username;
	}
	
	public void setPassword(String setPassword){
		this.password = password;
	}
}

Jetzt ruf ich über den Controller die Methode authenticate auf speicher das Ergebnis in einem UserID-Objekt im Controller. Nun ruf ich im Model eine Funktion auf, die alle vorhanenden UserIDs auflistet und überprüfe ob es die eingegebene UserID gibt. Wenn ja login wenn nicht nocheinmal.So richtig?

-GhostfaceChilla-

 

[rme]

Die UserID-Klasse ist schonmal gut, im MVC-Muster wäre das dann ein Model. Allerdings sollte es nicht so sein, dass die GUI selbständig Model-Klassen erzeugt - das ist Aufgabe des Controllers. Die authenticate-Methode gehört in den Controller und bekommt Name und Passwort als String-Parameter von der GUI. Der Controller kann dann das Model fragen, ob so ein Benutzer existiert.

 

[GhostfaceChilla]

Ok,also habe ich sozusagen die UserID als Model so. Dann brauch ich sozusagen in der GUI eine Methode die mir Name und Passowort an den Controller liefert. Also ich rufe mit dem Controller die Funktion zum herausfinden der eingegebenen Daten der GUI auf und dann rufe ich über den Controller das Model auf und überprüfe ob es so eine UserID gibt. Also so würde ich das jetzt machen. Mein Hauptproblem bestand nämlich darin, wie ich die Daten von der GUI 'schön' an das Model weiterleite über den Controller.

-GhostfaceChilla-

 

[rme]

Genau, das klingt gut. Die GUI sollte nichts über den Aufbau des Models wissen, deshalb der Weg über den Controller.

 

[GhostfaceChilla]

Also hab das jetzt mal so gemacht, muss noch drann rumfeilen aber wollte mal wissen ob es so vom Konzept her ok ist.

Der Controller:

import gui.LoginGUI;

public class Controller implements ActionListener {

	private LoginGUI gui;
	private UserID model;
	
	public Controller(){
		gui = new LoginGUI(this);
		model = new UserID();
	}

	@Override
	public void actionPerformed(ActionEvent arg0) {
		switch(arg0.getActionCommand()){
		case "ACT_LOGIN"	:	model.setUsername(gui.getUsernameFromUser());
								model.setPassword(gui.getPasswordFromUser());
								authenticate();
								break;
		default				:	break;
								
		}						
	}
	
	private ResultSet openDB(){
		ResultSet rs = null;
		try {
			//Datenbank öffnen
			Class.forName("com.mysql.jdbc.Driver");
			Connection con = null;
			con = DriverManager.getConnection("jdbc:mysql://127.0.0.1:3306/UserID_DB", "root", "highschoolhigh");
			Statement statement = con.createStatement();
			final String QUERY ="SELECT*FROM UserID";
			rs = statement.executeQuery(QUERY);
			
		} catch (ClassNotFoundException e) {
			System.err.println("Treiber nicht gefunden!");
			e.printStackTrace();
		} catch (SQLException e) {
			System.err.println("Kann nicht zu DB verbinden!");
			e.printStackTrace();
		}
		
		return rs;
		
	}
	
	private void authenticate(){
		ResultSet rs = openDB();
		try {
			while(rs.next()){
				if(model.getUsername().equals(rs.getString(2))
						&& model.getPassword().equals(rs.getString(3))){
					System.out.println("Yes");
					break;
				}
				else{
					System.out.println("No");
					break;
				}
			}
		} catch (SQLException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}

}

Die GUI:

package gui;

import java.awt.Color;
import java.awt.GridLayout;
import java.util.HashMap;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.JPasswordField;
import javax.swing.JTextField;

import controller.Controller;
import models.UserID;

public class LoginGUI {

	private JFrame window;
	private JPanel panel;
	private JLabel username;
	private JLabel password;
	private JLabel emptyBlock;
	private JTextField usernameFromUser;
	private JPasswordField passwordFromUser;
	private JButton login;
	
	
	public LoginGUI(Controller con){
		
		window = new JFrame("Login");
		window.setSize(400,100);
		window.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		
		panel = new JPanel();
		panel.setBackground(Color.WHITE);
		panel.setLayout(new GridLayout(2,3));
		
		username = new JLabel("Benutzername");
		panel.add(username);
		usernameFromUser = new JTextField();
		panel.add(usernameFromUser);
		emptyBlock = new JLabel();
		panel.add(emptyBlock);
		password = new JLabel("Passwort");
		panel.add(password);
		passwordFromUser = new JPasswordField();
		panel.add(passwordFromUser);
		login = new JButton("login");
		panel.add(login);
		login.setActionCommand("ACT_LOGIN");
		login.addActionListener(con);
		window.add(panel); 
		window.setVisible(true);
		
	}
	
	public String getUsernameFromUser(){
		return usernameFromUser.getText();
	}
	
	public String getPasswordFromUser(){
		return passwordFromUser.getText();
	}
	
}

Und das Model

package models;

public class UserID {

	private String username;
	private String password;
	
	
	public UserID(){
		
	}
	
	public String getUsername(){
		return username;
	}
	
	public String getPassword(){
		return password;
	}
	
	public void setUsername(String username){
		this.username = username;
	}
	
	public void setPassword(String password){
		this.password = password;
	}
	

	
}

Aufgerufen wird es bei mir in der main durch erstellen des Controller Objektes. Ist das so soweit ok, also rein vom Schema her?

-GhostfaceChilla-

 

[rme]

Das sieht doch schonmal schön aufgeräumt aus Noch ein paar Anmerkungen:

* der Controller sollte kein ActionListener sein, sowas ist Aufgabe der GUI. Die GUI implementiert für jeden Button einen ActionListener, der eine Methode des Controllers aufruft. Übrigens braucht man seit vielen Jahren den Kram mit setActionCommand nicht mehr, da es innere Klassen gibt. Hier ein Beispiel, wie die GUI das machen könnte:

        login.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent e) {
                controller.onLoginRequest(usernameFromUser.getText(), passwordFromUser.getText());
            }
        });

Dadurch wird eine anonyme, innere Klasse erstellt, die ActionListener speziell für diesen einen Button implementiert. Beim Auftreten der Action ruft er eine Methode im Controller auf und übergibt ihr die relevanten Inhalte der Felder.

Vorteil: Der Controller muss keinen zentralen ActionListener haben und auch nicht angepasst werden, wenn sich an der GUI was ändert. Wenn sich die GUI ändert, muss sie sich einfach nur daran halten, im Controller onLoginRequest aufzurufen, egal ob das durch einen ActionListener oder sonstwas ausgelöst wird. So bleibt der Controller schön unabhängig davon, was die GUI da tut.

* der gesamte Datenbank-Kram gehört ins Model. Die onLoginRequest-Methode des Controllers sollte ungefähr so aussehen:

 public void onLoginRequest(String name, String password) {
    UserID user = UserID.authenticate(name, password); // statische Methode in UserID, die prüft, ob es so einen User gibt und ggf. zurückgibt
    if(user == null) {
       // sage GUI, dass Login falsch
    }
 }

* dadurch muss der Controller dann auch keine UserID-Instanz im Konstruktor anlegen, die wird erst bei Bedarf erstellt, nämlich sobald Daten vorliegen

 

[GhostfaceChilla]

Alles klar danke
Ja das mit der DB ist mir auch aufegfallen, das die ja eigentlich ins Model soll.

-GhostfaceChilla-