Schnittstelle zum User Interface...
-
Ich hab mal eine Frage, wenn man eine Software etwickelt und möglichst flexibel bezüglich des User Interfaces bleiben will, also Grundlagen für Konsolen-User-Interface, als auch GUI schaffen will, wie geht man da am sinnigsten vor?
Der Unterschied ist klar, Konsole arbeitet im Blocking Mode, ergo wartet "gibNummer", bis gibNummer etwas returned. In der GUI funktioniert das ja eher ziemlich anders, am nächsten kommt dem wohl ein Observer Pattern. Logik sagt -> gib Nummer, wenn Logik fertig ist, wird in der GUI eine Methode der Logik "zurück benachrichtigt". Das verdoppelt im grunde die Anzahl der Methoden, die mit nem Konsolen-interface kommunizieren (im Falle der GUI)
Gibt da nen Ansatz um möglichst flexibel zu arbeiten und vielleicht einen Mittelweg gehen?
Im Grunde ist bei mir der Fall so, dass ich seit Jahren GUIs entwickel und damals als Anfänger auch schön alles mit Konsole gemacht und als wir dann auf GUI umsteigen musste, musste die ganze Logik neu gemacht werden, weil wir noch nicht wussten, wie unterschiedlich die beiden Sachen sind.
In diesem Fall hier wird niemals eine GUI hinzukommen, aber ich würde gerne irgendwie zeigen, dass ich so umsichtig wie möglich plane.
Und ich würde die Konsole ungern gethreaded implementieren
-
Normalerweise schreibt man eine libfoobar, die sämtliche Funktionalität beinhaltet.
foobar ist dann einfach ein CLI-Progrämmchen, das diese Library verwendet und für KDE schreibst Du eben ein kfoobar oä.
-
Ja, aber wie kapsel ich die Kommunikation für mich am geschicktesten? Ich mein Konsole ist synchron, GUI ist asynchron und wenn auch die Logik ne Lib hat, wie gib mir Nummer, so erwartet die Logik ja sofort eine Antwort, die kann aber bei asynchronenen Aktivitäten wie Threads ja nicht sofort gegeben werden.
-
Meine Idee war, dass ich den View als Observer Pattern implementiere.
Meine Logik meldet sich am View an und wird benachrichtigt, wenn sich im View etwas ändert, das klingt für mich recht gut.
Das Problem ist nur, dass View ja eine Menge an verschiedener Zustände haben kann -> Namen eingegeben, Zahl eingegeben, Button gedrückt usw.
Da per Definition die Logik also eine update Methode hat, müsste diese ja immer ein einheitliches ZustandsObjekt bekommen und das wäre irgendwie ein Hammer Aufwand, quasi eine update methode, die ne Menge ifs oder switches hat und jedesmal prüfen muss, was sich gerade geändert hat, ob Name, ob Zahl, ob Button usw
-
du solltest mal zwischen ui logik und der restlichen programm logik unterscheiden.
-
Tu ich, logik ist Programm logik, der Rest vom View ist erstmal alles eins, bei dem Schritt sehe ich noch keinen Sinn, das noch detailierter zu trennen, ich rede von Observer -> Programmlogik, Subjekt -> View.
Ich meine hier die Kommunikation des Views als ganzes mit der Logik. Die alternative wäre ja, dass die Logik 100 Methoden wie "nameEingegeben", "alterEingegeben" usw hat
-
Mit dem Observer-Pattern bist du schon nah dran. Schau dir mal das MVC-Pattern an. Das beschreibt die Trennung von Präsentation, Steuerung und Modell.
Dennis
-
Danke
Da bin ich ja schon längst, ich implementiere MVC und will die Benachrichtigung vom Controller durch View durch den Observer erreichen.
Ich hab hier nur das Problem, dass sich die Änderung des Views in vielen Arten auswirkt, Beispielsweise kann ein Name eingegeben werden, wenn man einen Film sucht, oder wenn man seinen Namen eintragen will. Oder ein int wird beim Alter übergeben usw.
Und mein State, was vom view an controller übergeben wird, muss ja irgendwie die art der übergabe und den wert rüber schicken
-
üblicherweise hängt man einfach an jedes objekt, das auf usereingaben reagieren soll, nen eigenen observer. für manche views lässt sich das auch zusammenfassen (man braucht nicht einen observer für jede zelle einer tabelle), aber es ist auch unüblich, einfach alle events zentral in einem observer zusammenzufassen. kann man theoretisch machen, aber dann werden deine events komplizierter (müssen viele informationen über sender enthalten), der observer nen ungelenk fettes teil und irgendwann bist du dann soweit, dass du nicht mehr weiterkommst, ohne dir laufzeitinformationen zu besorgen.
also teil es lieber in viele kleine observer auf.
-
Aber ein Observer ist doch ein Objekt, ich hab eine Logik, wie soll die bei mehreren verschiedenen Events benachrichtigt werden? Ich mein der Observer implementiert ja eine update Methode, so müsste ich mehrere Objekte mit update Methoden haben, und die wären ja noch trivialer, als wenn ich für jede Antwort des Views eine Gegenmethode in der Logik hätte, mit Klassen hätte ich das gleiche, nur mit dem Overhead, dass ich nicht eine Methode, sondern eine ganze Klasse mit dieser einen Methode schleppe