OOP MVC & Threads

[FightClb]

Wie kann man ein MVC basiertes Programm mit Threads verwirklichen?
Die Vorstellung wie die Klassen

main,model,view unc controller aussehen:

package sudoku;

import model.Model;
import view.View;
import controller.Controller;

public class Main {


    //Konstruktor
    public static void main(String[] args) {
        Model model = new Model();
        View view = new View(model);
        Controller controller = new Controller(model, view);
    }

}


package model;

import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;

public class Model {


    // Attribute
    private PropertyChangeSupport support;


    // Konstruktor
    public Model() {

        support = new PropertyChangeSupport(this);
    }


    // Methoden

    public void addPropertyChangeListener(PropertyChangeListener listener) {
        support.addPropertyChangeListener(listener);
    }
}

package view;

import java.awt.event.ActionListener;
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import javax.swing.JFrame;
import model.Model;

public class View extends JFrame implements PropertyChangeListener {


    // Attribute
    private Model model;


    // Konstruktor
    public View(Model model) {
        this.model = model;
        /*Fenster anpassen*/
        this.setVisible(true);
    }


    // Methoden

    public void addAllActionListener(ActionListener actionListener) {
        //Diese Methode wird für den Zugriff des Controllers benötigt
    }

    public void propertyChange(PropertyChangeEvent evt) {
        /*Hier die auf Anweisung des Models zu geschehenen Veränderungen des
         *Frames einfügen
         */
    }
}

package controller;

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import model.Model;
import view.View;

public class Controller implements ActionListener {


    // Attribute
    private Model model;
    private View view;


    // Konstruktor
    public Controller(Model model, View view) {
        this.model = model;
        this.view = view;
        view.addAllActionListener(this);
        model.addPropertyChangeListener(view);
    }


    // Methoden
    public void actionPerformed(ActionEvent e) {
        /*Hier die möglichen Events berücksichtigen und dem Model mitteilen*/
    }
}

 

[SlaterB]

am grundsätzlichen Aufbau ist bisher sicher nichts verkehrt,
wer kennt wen direkt oder indirekt per Listener entspricht genau dem Grundschema,

von Threads ist aber noch nichts zu sehen, oder?
grundsätzlich läuft quasi jedes Programm mit Threads wenn es auch ohne geht und andersrum genauso,
wobei 'mehr Threads' immer leichter einzubauen sind als Threads rauszunehmen 😉

 

[FightClb]

Also ich habe zur Zeit ein Sudoku-Projekt, das bisweilen ohne das künstliche Erzeugen von Threads funktioniert.
Ich wollte jetzt aber, während das model das Sudoku löst, dass das View die Anzeige aktualisiert.
Da das JFrame aber beim laden gefroren ist, kann der User die Veränderungen der Buttons erst nach Abschließen der Lösungsschleife sehen (selbst wenn ich die Methode view.refresh(); ausführen lasse, die die ButtonNamen aller Buttons neusetzt.)
Über System.out.println konnte ich sicherstellen, dass die Methode wirklich während der Schleife aufgerufen wird, allerdings wird die Anzeige nicht aktualisiert.
Ich bekam die Empfehlung dies mit Threads zu verwirklichen, allerdings stehe ich auf dem Schlauch, wie ich das schaffen soll...

Momentan erstellt die Main halt model, view und controller.
Model enthält die Daten und Methoden zur Modellierung
View ist ein JFrame und enthält alle Buttons etc
Controller enthält einen ActionListener (der zB den Befehl, des Sudoku-Lösens) übergeben bekommt.


Während der while()-Schleife der Methode sudokuLösen des Models, bringt es jedoch nichts, den view über die Methode refresh() die Aufgabe zu geben, die Buttons zu aktualisieren, da die Anzeige des Frames nicht erneuert wird. Hier brauche ich bitte Hilfe.

Ich kann gerne das gesamte Netbeans-Projekt aber auch Quellcodes einzelner Klassen hinzufügen, falls erwünscht.

Vorschläge, wie sich das Erneuern der Anzeige auch ohne Threads verwirklichen lässt, sind auch willkommen.

MfG
FightClb

 

[SlaterB]

das Problem ist altbekannt bei Swing, solange ein Listener irgendeine Aktion ausführen muss ist die GUI blockiert,
da derselbe Thread, der zeichnet, auch den Listener startet,
sowas kann man bei Swing grundsätzlich ohne Threads kaum lösen, wobei das teils nur wenige Zeilen Arbeit sind, nicht unbedingt große neue Klassen

es gibt da zwei Möglichkeiten:
1.
in Anlehnung an deinem vielleicht gedachten Konzept läuft zumindest der Controller als einer Thread, die View im Falle von Swing sowieso,
die View informiert den Controller nur was zu tun ist, ohne die Aktion direkt zu starten, legt etwa eine Email mit dem Auftrag in das Postfach,
das ist blitzschnell fertig, dann kann Swing wieder zeichnen,
der Controller-Thread läuft selbstständig und bemerkt die neue Nachricht und startet dann gegebenenfalls länger-dauernde Aktionen
2.
das klassisch einfache Prinzip:
aus einem Listener

actionPerformed() {
 xy();
}

wird

actionPerformed() {
  neuen Thread starten, der xy(); aufruft
}

ohne groß über MVC oder Benachrichtung nachzudenken läßt man einfach die ganze Arbeit in einem neuen aktuellen Thread ablaufen,
funktioniert erstmal auch,
und für die normalerweise überwiegende Menge der sehr kurzen Aktionen kann man auf diesen Umweg verzichten

statt direkt Thread ist SwingWorker da ein gutes Stichwort
Lesson: Concurrency in Swing (The Java™ Tutorials > Creating a GUI With JFC/Swing)

 

[FightClb]

Vielen Dank, habs so implementiert wie du gesagt hast. Alles läuft. So sieht's zur Zeit aus (einen Generator hab ich noch nicht), wer noch Empfehlungen hat: you're welcome 🙂

Sudoku.jar

Notiz: Dies soll kein Unterhaltungsprodukt werden, sondern nur als Beilage zu meiner Facharbeit (Thema: Sudoku - Lösungsalgorithmen und Implementierung) dienen.

 

[Firestorm87]

- Naja die Standarthöhe des Frames ist höher als die von vielen Bildschirmen (zumindest auf Notebooks 😛)

- Es wäre cool wenn man die Zahlen eintippen könnte statt nur durch weiterklicken...

Ebenfals man könnte eine durchgehende Prüfung bei neuen Eingaben zulassen (Deaktivierbar), so dass Zahlenkollisionen sofort rot hinterlegt werden...

So far.. meine ersten kleinen Ideen 🙂