Design für grafische Objekte die mit Daten verknüpft sind?
Hi,
ich möchte eine Art grafischen Klassendesigner programmieren. Ähnlich wie bei Klassendiagrammen soll man die Klassen als bewegliche Rechtecke dargestellt mit Verbindungen und Informationen wie Methoden, Eigenschafte usw. ausstatten können. Später sollen vielleicht die Klassenrümpfe generiert werden.
Vorneweg, ich weiß, dass es schon fertige Programme gibt, aber ich wollte so etwas selbst programmieren um C# zu lernen.
Zur grafischen Darstellung gibt es hier super Tutorials und ich habe das gut im Griff.
Mein Hauptproblem liegt im Softwaredesign und bei der Planung. Hier herrscht die große Unsicherheit, weshalb ich euch um Rat bitte.
Konkreter: Wie baue ich so etwas auf ohne die Grundlagen der OO zu verletzen und ohne mir bei einer späteren Erweiterung ins Knie zu schießen? Wie trenne ich sinnvoll Daten, Gui und den Rest (Stichwort MVC-Pattern)?
Folgende Fragen stellen sich mir:
Das Grafikobjekt "Klassenrechteck", welches die Klasse darstellen soll, soll es auch die Informationen zur Klasse (Methoden-, Feldnamen usw.) Speichern? Dann wären jedoch Gui und Daten vermischt.
Oder sollte es umgekehrt gemacht werden, so dass das Datenobjekt ein Grafikobjekt von sich selbst erzeugt? Dann gibt es ja wieder keine Trennung von Gui und Daten, oder?
Wenn ich ein Datenobjekt für Klassendaten und eines für dessen Grafikdarstellung, verwende kann ich diese beiden dann sinnvoll und unkompliziert gleichzeitig verwalten (Änderungen synchronisieren, Erstellen, Löschen)?
Zuletzt habe ich mir überlegt, als Klassengrafik-Objekt ein Usercontrol zu erzeugen, weiß aber nicht ob das eine glückliche Wahl ist. Anbindung der Daten über Databinding?
Nun ja, ich hoffe auf zahlreiche Tipps und Tricks die mir Licht ins Dunkle bringen.
Gruß
xbredoillex
hallo,
mal paar Anmerkungen dazu meinseits bzw. wie ich das angehen würde:
Das Grafikobjekt "Klassenrechteck", welches die Klasse darstellen soll, soll es auch die Informationen zur Klasse (Methoden-, Feldnamen usw.) Speichern? Dann wären jedoch Gui und Daten vermischt.
Oder sollte es umgekehrt gemacht werden, so dass das Datenobjekt ein Grafikobjekt von sich selbst erzeugt? Dann gibt es ja wieder keine Trennung von Gui und Daten, oder?
Auf jeden Fall die Objete trennen - die grafische Darstellung hat nichts mit dem Objekt an sich zu tun. Sieh es einfach so: Du möchtest, dass deine Objekte mit Winforms und WPF darstellbar sind...oder am Drucker ausgebbar. Wenn du da die Anzeigelogik ins Objekt programmierst, geht das nicht.
Es gibt also eine "Datenhalterklasse", welche Properties wie Methodennamen, Feldnamen usw. hat.
Dann eine eigene GUI Klasse, welche weiß wie man z.B. eine solches Objekt in Winforms grafisch darstellt. Hier kannst du ein Usercontrol als Basis verwenden.
MVC oder MVVM sind schon gute Ansätze, würde ich jedoch in der 1. Ausbaustufe weglassen - immer 1 Schritt nach dem anderen. 😉
fg
hannes
Das mit dem Drucken etc klingt einleuchtend. Wenn ich es richtig verstanden habe, sollen die Objekte hierarchisch auf gleicher Ebene existieren.
Angenommen, ich habe in meiner zukünftigen Anwendung einen Button "Klassenvorlage erzeugen". Dann entstehen bei jedem Klick zwei zusammengehörende Objekte: das Grafikobjekt der Gui-Klasse (evtl. Usercontrol) und das Datenhalterobjekt für die ins Grafikobjekt eingegebenen Klassendaten.
Da sich die Objekte nicht kennen (sollte wohl auch so sein um flexibel zu bleiben), weiß ich nun nicht, wie ich diese verwalten soll. Schließlich kommt ja mit jedem Klick ein weiteres Objektpaar hinzu und es kann auch sein das mal eines gelöscht werden muss oder editiert werden soll.
Meine Idee, die Objektpaare in einer Liste zu verwalten, zwingt mich irgendwie das Paar in einer weiteren Listenelement-Klasse zu Kapseln. Damit wäre aber wieder eine Verbindung von Gui und Daten geschaffen.
Irgendwie komme ich immer wieder an diese Stelle und dort jedoch mangels an Erfahrung nicht weiter 😃.
Ich erweitere mal die Topicfrage mit: ...und wie verwalte ich gewisse Anzahl an Gui-Daten-Objektpaaren, deren Objekte sich nicht kennen sollten?
Auf welche Art würdest du denn diese Objektpaare verwalten, so dass Änderungen am Gui-Objekt eine Objektpaares sich auf das zugehörige Datenobjekt auswirken u.u.?
hallo,
Das mit dem Drucken etc klingt einleuchtend.
ja, betrachte die eigentlichen Daten (welche du speichern/drucken/sonstwas kannst), immer unabhängig von deren Repräsentation.
Angenommen, ich habe in meiner zukünftigen Anwendung einen Button "Klassenvorlage erzeugen". Dann entstehen bei jedem Klick zwei zusammengehörende Objekte: das Grafikobjekt der Gui-Klasse (evtl. Usercontrol) und das Datenhalterobjekt für die ins Grafikobjekt eingegebenen Klassendaten.
ja. Wobei diese Logik nicht in das Klick-Event des Buttons programmiert werden soll, siehe z.B. MVP Pattern.
Da sich die Objekte nicht kennen (sollte wohl auch so sein um flexibel zu bleiben), weiß ich nun nicht, wie ich diese verwalten soll. Schließlich kommt ja mit jedem Klick ein weiteres Objektpaar hinzu und es kann auch sein das mal eines gelöscht werden muss oder editiert werden soll.
Nein, ich danke, dass das GUI Objekt das Daten-Objekt sehr wohl kennen "darf", jedoch nicht umgekehrt d.h. das Daten Objekt weiß nichts davon, dass es z.B. auf einem Winform angezeigt wird.
Die GUI Objekte kann man einfach in einer Liste speichern. Jedes GUI Objekt hat eine Referenz auf sein "Daten Objekt". Auf diese Weise würde ich die Objektparre verwalten. Im Idealfall ist die Referenz noch auf ein Interface des Daten Objektes.
Du kannst dir auch anschaun, wie z.B. #Develop das gelöst hat - die haben ja auch einen GUI Designer, der das selbe "Problem" hat. Ich denke jedoch, dass es hier (ohne es selbst gesehen zu haben) recht komplext wird, das das Projekt einfach einen enormen Umfang hat.
Für den Anfang würde ich wie beschrieben beginnen:
- 2 Objekte (Datenhalter bzw. "Domain Objekt")
- GUI Objekt, welches eine Referenze auf ein Daten Objekt hat
fg
hannes
Hallo,
danke, du hast mir jetzt meine Unsicherheit genommen, in drei Wochen wegen eines falschen Ansatzes von vorne beginnen zu müssen. 😃
Genau so werde ich es machen:
Erst ohne GUI programmieren, dann eine GUI erstellen bei der jedes Grafikobjekt eine Referenz auf das Datenobjekt hat. Die Grafikobjekte sind voraussichtlich Usercontrols Diese werden in einer Liste verwaltet.
Ich habe schon versucht ähnliche Projekte zu finden um eine Lösungsmethode für dieses "Problem" zu klau..., ähh, um mich inspirieren zu lassen. Aber leider habe ich trotz langer Suche nichts brauchbares finden können.
#Develop ist super, leider ist es schon sehr schwierig eine bestimmte Stelle im Quellcode zu finden. Den Code dann im Zusammenhang mit dem Gesamtprojekt zu verstehen und ihn auf mein "kleines" Problem herunter zu brechen fällt mir noch schwerer.
Zwecks Referenz auf das Datenobjekt, wie meinst du das hier genau?
Im Idealfall ist die Referenz noch auf ein Interface des Daten Objektes.
Gruß
xbredoillex
hallo,
na das freut mich aber, wenn ich dir da die Unsicherheit nehmen konnte. 😉
btw. wegen eines falschen Ansatzes neu zu beginnen ist nicht schlimm - vor allem, wenn es kein Produktiv-Projekt ist, sondern zur Übung dient - das nennt man dann "Refactoring". 😁
Auch in anderen Sourcen zu stöbern, ist eine gute Möglichkeit, sich Wissen anzueignen, würde das nicht als "klauen" bezeichnen.
Zwecks Referenz auf das Datenobjekt, wie meinst du das hier genau?
Damit meine ich eigentlich nur, dass es nicht so sein sollte, dass dein GUI Objekt eine Referenz auf eine Klasse (=Implementierung) deines "Daten-Objektes" haben soll, sondern auf ein Interface (=Contract) deines "Daten Objektes". Das soll jetzt aber nicht heißen, dass man es so machen MUSS.
Generell sollte man aber versuchen, wenn ein Objekt eine Referenz auf ein anderes Objekt hat, dies über ein Interface abzubilden => "program against an interface/contract, not an implementation". Dadurch wird die Kopplung zwischen den konkreten Objekten aufgehoben. D.h. du kannst die dahinterliegende Implementierung austauschen.
Weiters ermöglicht dir dieser Ansatz später die einfachere Verwendung von Mocking (für Unittests) oder von Dependency Injection.
fg
hannes