✔ How To: Interfaceprogrammierung

[Unicate]

Hi Leute!

Wenn ich ein Programm schreibe, welches eine Oberfläche hat, sollte man diese laut der 3 Schichtenarchitektur komplett von dem Rest des Programms trennen.
Wie macht man das?

Meine Vorstellung sieht bisher so aus (erscheint mir allerdings ein wenig "dreckig")

Meine Klasse WhateverGUI bekommt eine statische methode mit der sich das GUI aufbaut und für jedes Textfeld/Area oder was auch immer, erstelle ich eine puplic methode mit welcher
das jeweilige Element setzbar und lesbar wird.

public class GUI {
    public static void starteGUI() {
    ...
    }
    public String getName() {
        // returns name von textfeld name
        return ...
    }
}

Ich kann mir nicht vorstellen das das so "gemacht wird". Wie mach ich's richtig?

 

[Kai008]

Ich mache es immer so, dass es eine statische Methode in einer Klasse gibt, die die GUI aufbaut. Dadurch muss ich auch keine Klassenvariablen in dieser Klasse anlegen und spaare mit die Get-/Setter. Wenn ein Comp ein Interface (Listener) benötigt überschreibe ich ihm. Meistens wird innerhalb dieser dann ein Thread gestartet, der die Verarbeitung übernimmt.

Damit habe die Logik nur in der run, wo sie von der GUI getrennt ist. Als Struct hält meistens dann noch eine seperate Klasse hin, die oft statische Variablen und Get-/Setter enthalten.

 

[Akeshihiro]

Mit den drei Schichten ist in der Regel das MVC-Pattern gemeint (ModelViewController). Dabei geht es einfach darum, dass man die Daten, die Logik und die Präsentation von einander trennt. Sinn und Zweck dahinter ist die Austauschbarkeit von Komponenten auf einer "Schicht" ohne die anderen anpassen zu müssen.

Hier mal ein Beispiel, wie das ganze aussehen kann: klick
Und ein Wiki-Eintrag: klick

Wie du deine GUI (View) erstellst ist deine Sache, du musst für dich selbst einen Stil finden, der dir gefällt und mit dem du klarkommst. Ich habe z.B. mir einen Stil angeeignet, der bestimmte Parts der Codegenerierung vom VE in Eclipse und des Designers aus NetBeans enthält. Bei Bedarf kommen noch eigene Ideen hinzu, je nach Fall. Die Hauptsache bei der Implementierung des MVC ist, dass du eigene Events für das View und Model implementierst, damit das View dann den Controller kontaktieren kann, falls sich was im View getan hat (z.B. Button geklickt) bzw. das Model die View kontaktieren kann, wenn sich Daten geändert haben (oder Model den Controller kontaktieren, falls alles über den Controller läuft). Die Schichten kommunizieren also über Events (außer von Controller-Seite, er steuert sowohl Views als auch Models). Damit der Controller also im View und Model was machen kann, müssen entsprechende Methoden zur Steuerung bereitgestellt werden und damit entfällt dann auch die Notwendigkeit die Komponenten nach Außen hin verfügbar zu machen, muss es sogar, da sonst der Controller an eine GUI gebunden wäre und die View immer eine GUI sein müsste (Vermischung des View und Controller) und das ist wiederum nicht Sinn der Sache.

Ich kanns nicht so gut erklären, deshalb würde ich sagen, schau dir einfach das Beispiel an, das ich verlinkt habe oder such nach weiteren, Google ist da sehr großzügig mit den Ergebnissen.

 

[Unicate]

@Akeshihiro:
Die 3 Schichten Architektur teilt sich in:
Präsentation (Was bei MVC de View entspricht)
Datenhaltungsschicht - laden,speichern und halten von Daten (z.B. Hibernate, Was nicht ganz dem Model der MVC entspricht, denn laden und speichern in der MVC sollte doch der Controller übernehmen oder?)
Logikschicht

Bin mir da nicht 100% sicher, aber ich glaube MVC und 3 Schichten Architektur sind 2 paar ähnliche aber nicht gleiche Schuhe.
Das ist jedenfalls das was ich aus den Vorlesungen in Softwareengineering mitgenommen habe. (Habe den Proffessor extra deswegen nochmal gefragt) Allerdings ist irren auch menschlich.
Wenn's jemand 100% weiß, dann raus damit.


Danke, du hattest meine Frage aber verstanden(da View in der 3LayerArchitecture und der MVC sich ähneln) und ich versuch mir das gerade an zu tun.

 

[Akeshihiro]

Ob das wirklich das Selbe ist weiß ich grad leider auch nicht, aber so wie ich das bis jetzt rausbekommen habe läuft es auf das Selbe hinaus, deswegen dachte ich, dass es das wär.

Und ob das Laden von Daten die Sache des Controllers ist sei mal dahingestellt, es kommt auf das Design an. Ich habe das Model bisher immer als Datenquelle implementiert, das heißt auch als Datenbankschnittstelle, wenn es sein musste, da es dem Controller vollkommen egal sein kann von wo die Daten kommen, hauptsache der Controller kommt über das Model an die Daten, die es benötigt. Man kann das Model auch "dumm" sein lassen und dann immer von Hand Daten einfügen. Der Controller hat in meinen Augen in erster Linie mit der Logik der Anwendung zu tun und braucht sich da nicht noch mit der Datenherkunft rumschlagen.

Soweit ich weiß gibt es auch keine bestimmte Vorgehensweise beim MVC, da es doch sehr offen designt wurde und keine konkrete Vorgaben bekannt sind (soweit ich weiß zumindest) und man deswegen seine eigenen Ideen gut umsetzen kann. Viele Implementierungen weichen sogar von dem UML-Diagramm ab und lassen den Controller sowohl das Model verwalten als auch die View aktualisieren, also quasi als Proxy, dabei soll sich die View laut UML selbst die Daten aus dem Model holen. Also ich denke es ist alles eine Frage des Designs ...

Aber wie du schon sagtest, irren ist menschlich und ich lasse mich auch gern korrigieren, schließlich will ich nicht später erfahren, dass ich die ganze Zeit über falsches Wissen mit mir rumgeschleppt hab xD

 

[Unicate]

Ich bin auch einer der Vertreter, der "die View sollte keinen direkten Kontakt mit dem Model haben"-Theorie.

So kann man sowohl die View als auch das Model in anderen Projekten wiederverwenden. (In wie weit sich das verwenden lässt sei mal dahin gestellt, denn gerade die View wird sich in 2 verschiedenen Projekten kaum ändern)
Wenn man z.B. seiner Applikation ein neues Aussehen verpassen will muss man das Model dafür nicht anrühren.

Danke aber, es ist gut zu wissen das ich nicht der einzige bin der dabei im dunkeln tappt.