C++ und die Menge an Files (Dekorator/Notifier Pattern)

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.

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...

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 )...