Hallo zusammen, ich bin dabei eine C++ Applikation zu entwerfen, bei der es funktional einen logischen Kern gibt und je nach Zielplattform eine Visualisierung. Jetzt ist es natürlich sinnvoll, für den funktionalen Kern für die jeweilige Plattform die selbe Codebasis zu verwenden. Die "oberflächliche Realisierung" (lustiges Wortspiel, wa?!) soll einmal µC-basiert auf TI-GrLib sein und das andere Mal Qt. Nach meinem Verständnis würde ich bei den Elementen, bei denen es etwas an zu zeigen gibt, eine Callbackfunktion vorsehen, um ein übergeordnetes Objekt dazu zu bewegen etwas anzuzeigen. So wie ich das sehe, wird sich dadurch die Anzahl der Files ungefähr verdoppeln, da ich für jedes Element ein File mit der Kernlogik habe und den GUI-Decorator? D.h. meine Projekte werden quasi vor Files platzen. Das ist normal nehme ich an? viele Grüße!
Ich kenne das angesprochene Pattern nicht, ähnelt das dem Observer Pattern? In diesem Fall hättest du eine einfache Business-(Logik-)schicht und eben eine Schnittstelle dazu die von einer oder der anderen Visualisierung bedient wird.
Von wie vielen hunderttausend Files gehst du denn in etwa aus? Ansonsten ergibt das doppelte von ein paar Files halt ein paar mehr Files. So what. Aktuelle Filesysteme können eine ganze Menge davon verwalten;) Oliver
Für solche Fälle ist das Observer Pattern üblich. Und C++ verbietet dir nicht, mehrere Klassen in eine Datei zu packen... wenn das nicht gerade zufällig zusammen gewürfelte sind, ist das auch nicht besonders hässlich.
Ich meinte eigentlich nur, ob das normal ist mitz Menge an Files, um mich zu vergewissern, dass ich nicht einem Flaw aufsitze. Was ich nicht glaube...
Mach dir keinen Kopp. Du kannst ja spaßeshalber mal nachzählen, wie viele Dateien alleine die Standardlib oder TCL bzw. Qt mitbringen. Dagegen kannst du deine paar selbstgeschriebenen vernachlässigen. Entscheidend ist da nur, daß du für dich und für andere eine verständliche Struktur aufbaust. Die Navigation selbst durch tausende Sourcefiles ist dank leistungsfähiger Editoren doch nun überhaupt kein Problem. Oliver
:
Bearbeitet durch User
Milhouse van Hauten schrieb: > Nach meinem Verständnis würde ich bei den Elementen, bei denen es etwas > an zu zeigen gibt, eine Callbackfunktion vorsehen, um ein übergeordnetes > Objekt dazu zu bewegen etwas anzuzeigen. Es gibt grob zwei bekannte Architekturfamilien so etwas objektorientiert zu realisieren. Beide verwenden Callbacks. Daneben kann man sich selber andere Architekturen basteln. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller https://en.wikipedia.org/wiki/Presentation%E2%80%93abstraction%E2%80%93control Kaum jemand baut die in Reinform nach, aber sie werden gerne als Richtlinien genommen. PAC eignet sich besser für GUIs die aus relativ unabhängigen Komponenten bestehen. Ich würde bei beiden Architekturen nicht von irgendeinem übergeordneten Objekt reden. Alle müssen zusammenwirken. > So wie ich das sehe, wird sich dadurch die Anzahl der Files ungefähr > verdoppeln, da ich für jedes Element ein File mit der Kernlogik habe und > den GUI-Decorator? Ein Decorator, bzw. GUI-Decorator ist etwas anderes. Decorator ist ein Entwurfsmuster um die Funktionen von Objekte zu erweitern ohne das die Verwender der Objekte das mitbekommen. Das klassische Beispiel, und daher der Name, ist ein GUI-Fenster das mit einem Rahmen und Bedienelementen "dekoriert" wird. https://de.wikipedia.org/wiki/Decorator > D.h. meine Projekte werden quasi vor Files platzen. > Das ist normal nehme ich an? "platzen" ist relativ. Mein aktuelles Projekt enthält ca. 330 Quelltext-Dateien. Für mich ist das ein ziemlich kleines Projekt.
Und sofort wird eine abstrakte Diskussion über Design Patterns geführt statt sich mit der wichtigsten Frage erstmal zu befassen: Was wollen wir KONKRET machen? Wieviele Tage und Wochen in meinem Leben habe ich verbracht in sinnlosen Meetings wo solche idiotischen Diskussinen gefürt wurde und Leute die meistens null Ahnung davon haben, nämlich die Manager, noch ihren Senf dazu geben mussten.... Softwareentwicklung ist nicht abstrakt. Sie soll KONKRETE Aufgaben erfülllen. Zuerst muss man verstehen WAS gemacht werden soll, erst dann WIE. Und beim WIE gilt: Keep it as simple as possible. ALso keine unnötigen Frameworks, keine unnötigen ABstraktionsebenen, keine Anpassung der Aufgabe an ein Design Pattern ( häufigster Unsinn bei der Verwendung von ihnen )...
Klassisch wäre eine Trennung in Frontend (Visualisierung) und Backend (Kernlogik). Dazwischen definierst du dir eine beliebige Schnittstelle, die du dann einmal für jede Visualisierungsplattform implementierst. Infolgedessen darfst du dir dann für jede Plattform die am besten geeignetsten Programmiersprachen und Toolkits aussuchen (Java für Android, C für AVR, C++ und Qt für Linux, C# für Windows). Und jedes Projekt ist, für sich genommen, wesentlich kleiner und nicht stark mit den anderen verzahnt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.