Wie in meinem Projektthread (ja, da hat sich nochmal was getan ) schon angekündigt, hier mein Thread zum Thema Texturen...

Eigentlich hab ich weniger ein Problem mit der Implementation als mit der Frage: Wie mach ichs geschickt?

Folgende Ansprüche hab ich prinzipiell an mein Projekt:

a) Die GUI sollte auch ohne den Rest des Projekts funktionieren
b) Der Rest vom Projekt sollte auch ohne GUI funktionieren

Und der Moment, an dem Texturen ins Spiel kommen ist der Moment, an dem ich hier in einen Konflikt gerate. Ich orientier mich, was das Texturmanagement angeht momentan extrem am "Bomberman-Tutorial", der Texturmanager ist eigentlich sogar eine recht genaue Abschrift dessen, was dort benutzt wird.
Nun hab ich zwei Möglichkeiten:
Entweder, ich benutze für Projekt und GUI den gleichen Texturmanager, was leider dafür sorgt, dass ich gegen a) und b) verstoße. Der bedeutenste Nachteil ist da (denke ich), dass, wenn ich das GUI in einem anderen Projekt integrieren will, in dem das Texturmanagement (warum auch immer) anders aussieht, das GUI und das Texturmanagement nichtmehr "zueinander passen" könnten.
Oder, ich integriere einen Texturmanager in das GUI - das sähe dann im Moment in meiner Vorstellung so aus, dass die Ebene null (also der GUI-Manager), das mit aufs Auge gedrückt bekommt. Das widerspricht dann allerdings der Maxime, dass jede Klasse genau einen Zweck haben sollte...und sorgt dafür, dass jede Komponente nicht nur einen Pointer zu ihrer Parent-Komponente, sondern auch zum GUI-Manager brauchen würde, aber das ist eher eine Hürde ästethischer Natur.

Lasst mal bitte vom Stapel, was euch zu dem Thema durch den Kopf geht - ich hab bei der Sache momentan echt ne Blockade und hoffe, hier bringt irgendjemand nen Ansatz, der einigermaßen einfach zu implementieren und trotzdem funktionell ist...

Das Projekt in drei Teile teilen? Also den Texturmanager als eigenes Teilprojekt. Dann würdest du nicht mehr gegen a) und b) verstoßen.

_________________
Yeah!

Das wäre ja das was ich mit der ersten Möglichkeit meinte - ich hab einfach "Angst", dass ich dann irgendwann an nem anderen Projekt sitze, bei dem mir das aktuelle Texturmanagement nich ausreicht.
Dann schreib ich dafür nen neues, will mein GUI einbauen und das verträgt sich plötzlich nimmer miteinander.

Andererseits...sind das glaub ich einfach Paranoia, die Produkt meiner momentanen Blockade sind

Ich habe die Erfahrung gemacht das zu viel Planung auch nichts bringt. Meistens musst du später noch irgendwelche unvorhergesehenen Dinge einbauen. Ganz ohne Planung geht es natürlich auch nicht, aber es ist schneller das Konzept in kleinen Schritten anzupassen sobald es unübersichtlich wird. Es macht keinen Sinn bereits zu Beginn alles mögliche einzuplanen was dann später vielleicht gar nicht gebraucht wird.

Grundregel: Sobald eine Codestelle unübersichtlich wird konzipiere diesen Teilbereich in kleinen übersichtlichen Schritten neu ohne die Funktionsweise zu ändern. Stelle durch Unit-Tests sicher das noch alles korrekt funktioniert, dann weiter zum nächsten Änderungsschritt.

_________________
Yeah!

Mach doch eine basis klasse vom Texturmanager der nur eine abstrakte funktion à la getTexture(String filename) hat, dann kannst du davon 20 verschieden komplexe vatiationen eines Texturmanagers ableiten die halt alle mindestens diese funktion haben.

Und deiner GUI ist es dann egal wie komplex der Manager ist, denn sie benutzt nur diese eine funktion die immer da ist.

Ggf. kannst du natürlich auch mehr als eine funktion abstrakt machen;)

Aya

Coolcat:
Was genau versteht man eigentlich unter einem "Unit-Test"? Hab das jetzt schon öfter gelesen, kann mir darunter aber irgendwie nicht wirklich was vorstellen. Generell denke ich, du hast Recht - Überplanung tut dem Fortschritt nich wirklich gut

EDIT by Flash: Unittestdiskussion setzt sich hier fort.

Aya:
Ja, so was ähnliches hatte ich mir eben auch noch überlegt (auf dem Weg zur Mensa xD) - dachte, ich verpass der GUI einfach den ein oder anderen Callback Marke LoadTexture(Attribute), BindTexture(Attribute) etcpp., den der Benutzer dann selbst so füttern kann, das beim benutzten Texturmanager der richtige "Auftrag" ankommt. Immerhin (siehe Projektthread) spiele ich ja mit dem Gedanken, die GUI auch der Masse verfügbar zu machen.

Irgendwie sind hier 2 Themen drauß entstanden ^^

@UnitTest:
Edit by Flash: Wurde in den Unittestthread verschoben.

@GUI
Ich bastel aktuell eine implementierung von WPF für C++ und daher kann ich dir da eine gute Lösung nennen.
WPF liegt dem MVP(Model-View-Presenter) Pattern zugrunde, welcher sich nur durch eine Beziehungsänderung vom MVC(Model-View-Controller) unterscheidet.
Hierbei geht es darum, einmal Model von View und Presenter zu trennen, das Model stellt die Daten dar also UI-Element ist von Typ A, hat Werte X und Y und hat Z als Kind.
Zum Model gehört auch die Daten, um ein UI-Element vom Typ X zu zeichnen(z.B. Bilddaten, Vektordaten, Zeichenbefehle).
Das View ist die Visuelle Komponente und kann in diesem Pattern Problemlos entfernt werden und erlaubt somit Konsolenbetrieb und einfaches Unit-Testen.
In die View kommen z.B. GDI,OpenGL,Windows Window API als Klassen verpackt rein oder im Fall von Windows WPF D3D9(Standalone) und Silverlight(Web-Application).
Der Presenter kennt das Model, durch übergabe beim erstellen der entsprechenden Klasse und wird zur Laufzeit durch Events/Observer-Pattern/Signals/Message flach mit der View verbunden. Der Presenter ist die Logik, welche z.B. bei einem rein kommenden MouseMove Event am Model eine Variable ändert und testet ob die Mouse über einem Button liegt, um diese dann von einer anderen Presenter Funktion z.B. IsMouseOverButton der View zur verfügung stellen zu können. Die View kann dann anhand dieser Methode dann ein Button entsprechend Heller zeichnen oder halt Normal.

Könnte noch vieleicht ein bisschen verwirrend sein darum noch ein Beispiel.
Wenn du ein Delphi Projekt erstellst und einige Buttons darauf platzierst, sowie einigen Buttons OnClick Events verpasst dann hast du folgendes.
Canvas ist View, die OnClick-Events sind deine Presenter und die TButton,TForm und alles in der dfm(glaube so heisst die ^^ schon sehr lange her) wären Model.
Delphi arbeitet nicht nach dem MVP Prinzip, daher sind Model und Logik im form1.pas gemixt und der rest von Model liegt extern in der extra File.

Back to topic. Der Button : Du hast einen oder mehrere Texturmanager(Model), welche die Bilddaten laden und verarbeiten, ein DrawImage Funktion von einem Canvas(View), welche ein Image-Objekt entgegen nehmen kann und eine Widget Sammlung, welche ein ButtonWidgetLogic(Presenter) enthält. Dieses ButtonWidgetLogic erhält beim Erzeugen ein Namen, Index, Pointer oder oder eine andere Möglichkeit um an das zugewiesende Image-Objekt zu kommen und natürlich einige weite Infos, wie Position, Größe,... . ButtonWidgetLogic hat auch eine Funktion OnButtonDown, welche mit OnMouseButtonDown von einem Window/Viewport/Viewport3D/...(View) UI-Widget verbunden wird.
Um natürlich OnButtonDown an das OnMouseButtonDown von einem UI-Widget(z.B. Form) binden zu können muss man ButtonWidgetLogic beim erzeugen auch entsprechende Übergeben.
Wenn man diese nicht übergibt, wird dies entsprechend nicht gebunden und Model+Presenter laufen ohne View gemütlich weiter.

Microsoft nutzt als Zeichenvorlagen für Buttons, Panels, Windows und so weiter SVG ähnliche XML files, welche XAML heissen.
Das gleiche Format wird auch getrennt für ein neue Anwendung verwendet, also im Prinzip ist eine neue Anwendung nur eine neue UI-Komponente obwohl sie auch vielen verschiedenen bestehen kann. Der größte Unterschied zu SVG ist, dass man beliebig verschachteln kann, also ein Button kann ein weiteren button enthalten und dieser kann eine Taskleiste enthalten und diese ein Bild und so weiter und ohne restriktion ^^. Der 2. große Unterschied ist, dass man Methoden/Funktionsnamen auf Events zuweisen kann. Für ein besseres verständnis, das ist alles Model auch die Zeichenbefehlslisten. Presenter wird in C# abgebildet und View ist für den Entwickler versteckt hinter Klassen gekapselt, also die D3D und GDI Befehle wurden in handliche und allgemeine Interfaces definiert, welche von Presenter verwendet werden können. So kann man von z.B. Desktop Applikation auf ein Browser Plugin wechseln, ohne den Code nochmal anfassen zu müssen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Wenn es dazu wirklich kommen sollte, kannst du ja immernoch mit unterschiedlichen Versionen deines Texturmanagers arbeiten. Also die GUI mit einem älteren Tag deines Texturmanagers arbeiten lassen, solange bis die auch wieder etwas neues brauchst. Wenn die Anforderungen dann ähnlich sind, kannst du sie verallgemeinern und in das Basisprojekt Texturmanager überführen. Sind sie zu speziell erweiterst du den Texturmanager für die GUI und einmal für das andere Projekt und machst sie jeweils zum Teil der spezifischen Projekte.
So kannst du genau darüber bestimmen, welche Funktionen allgemein und damit für alle Texturemanager zugänglich sind und welche Projektspezifisch sind.

Prinzipiell solltest du keine Angst davor haben, ein wachsendes Projekt aufzusplitten und dann deine Projekte miteinander zu verbinden. Es fördert ungemein die Denkweise verteilter Anwendungsentwicklung. In größeren Verteilten Projekten ist es sogar sinnvoll, ganze API Projekte zu schaffen, die nur noch die Interfaces eines Moduls enthalten. Die eigentliche Implementierung der Interfaces liegt dann in einem anderen Projekt. Da man ja ohnehin nur gegen Interfaces entwickeln sollte, reicht es dann, das vollkommen allgemeine API interface-projekt zu referenzieren.