Frage von Crankie101, 35

Warum nimmt das Datenmodell keinen Bezug zur GUI?

Ich schreibe darüber nächste Woche ne Kursarbeit und ich weiß einfach nicht , warum das so ist. Ne Erklärung wäre wirklich klasse :D

Antwort
von WhiteGandalf, 23

Das hört sich mal wieder danach an, dass da ein Fundamentalist als Lehrer am Werkeln ist.

Nein, es gibt da keinen Gott des Datenmodellings und Datenanzeigings, der auf mystische Weise bewirkt, dass es Programmierern unmöglich oder aufgezwungen ist, eine Trennung ihrer Anwendung in Datenverarbeitung und Anzeige zu organisieren.

Es kann aber eine Menge gute Gründe geben, eine Trennung herbeizuführen und durchzuziehen, genauso wie es auf jeden Fall jede Menge gute Gründe gibt, warum zwischen beiden Teilen sehr wohl eine Beziehung existiert.

Gehen wir erstmal auf das letztere ein, um völligem Irrsinn vorzubeugen: Warum zum Teufel sollte jemand eine Datenverarbeitung für die Mülltonne aufstellen? Wenn er die verarbeiteten Daten überhaupt ganz und gar nicht anzeigen lassen wollen täte? Ist logisch zu beantworten, oder? NA KLAR lässt man Daten hinter einer Bedienoberfläche (für Menschen) genau zu dem Zweck verarbeiten, DASS die SEHR WOHL (dem Menschen) angezeigt werden. Alles andere wäre Humbug hoch drei.

Ergo wird die Anzeige der Daten SEHR WOHL SEHR DIREKT Bezug nehmen auf die verarbeiteten Daten.

Allerdings kann man sich MEIST (sofern nicht ein guter Grund für das Gegenteil spricht) sparen, in der Anzeige der fertig verarbeiteten Daten den Verarbeitungsvorgang darzustellen. Bzw. irgendwas aus dem Vorgang in die Anzeige hineinwirken zu lassen. - Wie gesagt: ES SEI DENN, es gäbe einen guten Grund, das DOCH tun zu WOLLEN. Es kommt auf die Aufgabenstellung und auf den Willen der Auftraggeber und Programmierer und Endnutzer an, was die ganze Chose letztlich bewirken soll.

Wenn man allerdings sich überhaupt einen Kopf macht, die Datenverarbeitung von der Datenanzeige zu trennen, dann HAT man MEIST einen guten Grund, eben genau KEINEN oder WENIG Einfluss der Datenverarbeitungsprozesse auf die Anzeige (-prozesse wie Endzustand) zuzulassen. Wer einen solchen guten Grund nicht hat und dennoch paranoid aus reiner Prinzipienreiterei Aufblähungen seiner Programme betreibt, hat es verdient, in Arbeitslast-Explosion zu ersticken. Wir gehen also mal davon aus, dass ein guter Grund zur Trennung existiert.

Dann... trennt man das halt. Eine Datenverarbeitung KANN man in aller Regel unabhängig von der Anzeige und VOR derselben implementieren. Die Anzeige KANN man in der Regel und zwar NACH der abgeschlossenen Datenverarbeitung implementieren. Und wenn man das KANN, dann TUT man das halt eben zur Trennung der beiden Komplexe. Die SCHNITTSTELLE zwischen beiden stellen die verarbeiteten Daten dar. Auf diese MÜSSEN sich beide Seiten des Komplexes gleich beziehen, sie muss KONSTANT sein. Mehr ist da auch schon nicht dran am Thema.

Wie man das im Detail einer konkreten Aufgabenstellung optimal umsetzt, ist Sache der konkreten Aufgabenstellung und muss für jede neu durchdacht werden.

Übrigens zwing auch kein Gott dazu, ein komplexes System in genau zwei Teile zu trennen. Eventuell ist es sinnvoll, in drei oder vier oder mehr Teile zu splitten. Eventuell (fast immer) ist eine hierarchische Strukturierung des Systems sinnvoll. Eventuell (sehr oft) ist es sinnvoll, Teile des Systems, das man entwickelt, als Bauteile auszulegen, so dass man sie in anderen Projekten wiederverwenden kann, ohne sie jedes Mal neu entwickeln zu müssen. Eventuell (meist) ist es sinnvoll, solche Bausteine in Bibliotheken zu sammeln und von der Schnittstellengestaltung und Funktion so einzurichten, dass sie sich universell kombinieren lassen. Und so weiter und so fort. Eine Trennung in Datenverarbeitung und Anzeige ist nur ein kleiner Aspekt der Entwicklung von EDV-Systemen, und hat nur eine Bedeutung für Systeme, die eine Anzeige (in der Regel für Menschen) haben.

Antwort
von mrhashpipeotto, 35

warum soll das datenmodel KEINEN bezug zur gui / view haben? SELBSVERSTÄNDLICH darf ein datenmodel einen bezug zur view haben und umgekehrt. zb ist reaktive programmierung  der neueste hit in der webentwicklung und genau diese beziehung zwischen model und view versucht man mit dem paradigma abzubilden so das zb bei einer datenänderung automatisch auch eine view änderungen stattfindet, also gibt es hier ganz klar einen beziehung :D

en.wikipedia.org/wiki/Reactive_programming

Antwort
von PeterWolf42, 33

Im welchem Kontext? Meinst du beim Model-View-Controller-Pattern?

Kommentar von Crankie101 ,

Na ja bei der Programmierung eben :DD Kann nur sagen das wir im Unterricht 4 Ampeln und fußgängerampel mithilfe objektorientierter Programmierung simuliert haben und dann dazu eine GUI erstellen sollen. Dabei war dann ein Modell abgezeichnet das das sagt. Hier der Link zur Website http://www.inf-schule.de/modellierung/ooppython/ampel/gui/erkundung_gui/guiklass... die untere Aufgabe , aber ich kommm da einfach icht drauf, danke für deine Hilfe !

Kommentar von PeterWolf42 ,

Der große Vorteil dieser Einteilung ist, dass das Datenmodell die GUI nicht kennt. So kann die GUI jederzeit durch eine andere ersetzt werden, ohne am Modell etwas ändern zu müssen. Ebenfalls kann das Datenmodell auch in anderen Programmen verwendet werden, da es zum funktionieren nur sich selbst braucht und keine weiteren Objekte. 

Ein weiterer Vorteil dieser Einteilung ist die Testbarkeit. Würde die GUI das Datenmodell kennen und umgekehrt, ist es schwierig zu Testen, da man zum Testen der GUI das Datenmodell braucht. Um dieses zu benutzen, muss es getestet worden sein, wofür man aber die GUI benötigt hätte. Also ein Teufelskreis.

Wenn jedoch das Datenmodell die GUI nicht kennt, kann es vollständig unabhängig getestet werden und wenn es dann funktioniert, kann die GUI getestet werden mithilfe des Datenmodells. 

Ich hoffe, das beantwortet deine Frage einigermaßen.

Keine passende Antwort gefunden?

Fragen Sie die Community