spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Dann bist du aber auch hart verdrahtet und abhängig. Du kannst die hässliche API (Db.Init() & Co) aber auch in einen Stream kapseln und den als Strategy übergeben.

so hässlich finde ich die API garnicht mal

Aber zurück zum Punkt:


Dein Fazit ist also, ich sollte kein explizites Strategy-Pattern (wie im Dateianhang) benutzen sondern einfach meiner ObjectStorageklasse im kOnstruktor einen Stream übergeben, habe ich das so richtig verstanden?

Soll heißen, du implementierst dir eine eigene Stream Klasse. Kommt mir so vor als würdest du da ein paar Dinge falsch verstanden haben.

Zitat von »JungleProgger«

Dein Fazit ist also, ich sollte kein explizites Strategy-Pattern (wie im Dateianhang) benutzen sondern einfach meiner ObjectStorageklasse im kOnstruktor einen Stream übergeben, habe ich das so richtig verstanden?

Jein. Du kannst das halten wie ein Dachdecker. Entweder baust Du Dir Deine eigenen Serializer-Klassen, die die Werte aus dem Objekt heraus holen und wieder da rein packen - und kannst diese als Strategy ansehen. Oder du übergibst dem Objekt einen Stream und da schreibt das Objekt seinen ganzen Kram rein - wobei der Stream letztlich sowas ähnliches wie eine Strategy ist. Der einzige Unterschied zwischen beiden ist die Richtung des Datenflusses. Ich persönlich mag die Stream-Variante, weil dabei nichts unnötig nach außen preisgegeben werden muss über interne Details und Status (merke: Mehrzahl von Status ist Status - mit lang gesprochenem U und nicht Stati). Streams würde ich aber nicht im Konstruktor übergeben, sondern dann, wenn es gebraucht wird. Wer weiß denn schon, ob das Objekt jemals serialisiert werden muss und dann wäre ein erforderlicher Stream im Konstruktor ziemlicher Käse.

Ok, jetzt habe ich Dich ganz gut verstanden

Danke nochmals für die ganzen Hilfen!

Eine Sache nur noch

Wenn ich es nach Deiner Methode machen würde, was ich denke ich auch tun werde, nur um beim Beispiel der Database zu bleiben:

wenn ich sowas habe wie

DBStream : Stream -----> ich hoffe du meinst das so

wenn ich dann DBStream habe, da ist das Problem, wenn ich Write aufrufe, dann erwartet er ja noch byte[] array, etc.. also alles in Byte-Form, da würde ich gerne aber sowas haben, wie

Write(object o)

das geht ja eig. nicht, weil ich ja vom Stream erbe.

Ich wäre Dir unglaublich Dankbar für ein wenig Code wie du es meinst

Zitat von »JungleProgger«

Nur was meinst du mit:

Zitat von »Tobiking«

Beim Laden fällt mir z.B. auf, dass man erst ein Objekt mit Default- oder Dummywerten erzeugen muss, damit man Read aufrufen kann und die richtigen Daten geladen werden. Das wirkt unnötig, weswegen ich schauen würde ob es einen Weg gibt eine Funktion zu schreiben, die mir direkt das Objekt mit geladenen Werten erzeugt.

Wenn ich "ReadFrom(input) : object" bei den jeweiligen Storages implementiere, wieso müssen da Dummywerte rein, das verstehe ich nicht

Huppla, da hab ich in der Schnelle zu oberflächlich über das Diagramm geguckt, den Rückgabetyp nicht gesehen und gedacht dein Plan wäre es die Methoden für Read und Write von Außen über das Objekt aufzurufen. In der Strategy ist bereits genau die Funktion von der ich gesprochen habe.

Zitat von »JungleProgger«

das geht ja eig. nicht, weil ich ja vom Stream erbe.

Offensichtlich sind triviale Streams für Datenbanken (im Sinne von Key-Value orientierten Daten) ungeeignet. Da ist ein eigenes Strategy-Interface mit einer write<T>(String key, T value) Methode natürlich besser geeignet. Es hängt halt alles von Deinem Use-Case ab. Ich würde dennoch vermeiden wollen sämtliche Interna nach außen preis zu geben, nur damit jemand anderes sie lesen und serialisieren kann.

Ok, danke Dir!

ich werde es mal nach dem Pattern versuchen, mit [Tkey, TValue] und probiere rum, so wie ihr es mir auch vorgeschlagen habt und danke für eure Geduld!

Ich würde Dir eher raten Deinen Use-Case genau zu betrachten. Solche Streams können sinnvoll sein, aber wenn eh eine Datenbank zur Diskussion steht, ist ein entsprechendes DB-Modell womöglich ratsamer. Da gibt's ja auch diverse schöne Bindings für, die einem die Arbeit abnehmen, sodass man kein SQL schreiben muss und eventuell sogar flexibel zu NoSQL wechseln könnte. Mir ist es in der Praxis noch nicht begegnet, dass man spontan zwischen File und DB wechseln können will. Höchstens in einer DB speichern und einen separaten Export machen als Json/Xml/whatever.

Also es steht nicht UNBEDINGT eine Datenbank zur Frage


Mir ginge es halt von Anfang an um Flexibilität, aber scheinbar lässt sich das nunmal nicht ganz so flexibel immer machen

Nachdem Motto:

Wenn du willst, kannst du zur Laufzeit in eine Datei schreiben, aber genau so in IRGENDEINE Datenbank oder von mir aus an einem anderen Server