nicht angemeldet
Hallo Eddie,
An der Lösung missfällt mir irgendwie, dass Du zwei Objekte hast, die letztenendes das gleiche Bild repräsentieren. Außerdem musst Du alle Funktionen doppelt implementieren.
Ich würde dem "Wrapper"-Objekt keine Schnittstelle geben, um die Detailinformation des Fotos zu erfahren. Wenn die jemand benötigt, soll er sich das referenzierte Objekt geben lassen und darauf zugreifen.
Nachdem ich deine anderen Postings gelesen habe, bin ich mir auch nicht mehr so ganz sicher, was wirklich die geeignete Lösung ist.
Die geht es ja doch vor allem um die Erzeugung des Objekts und nicht darum, mit einem sich ändernden Zustand klar zu kommen.
Wie lange exisieren denn diese NewFoto-Objekte und wird mit ihnen etwas gemacht, außer sie zu speichern?
Die einfachste möglichkeit, wenn sie nur kurz existieren und nur gespeichert werden, wäre wirklich eine Factory:
class FotoFactory {
Foto createFoto(...);
}
Diese sollte das Foto abspeichern und gleich eine Instanz mit allen Daten erzeugen.
Existiert das Objekt länger und Du brauchst wirklich so ein NewFoto-Objekt um das Speichern und Berechnen der Daten in irgend welchen Modulen zu erledigen, aber ansonsten passiert nichts mit dem Objekt, könntest Du so vorgehen:
class FotoDescriptor {
...
}
class FotoFactory {
Foto createFoto(FotoDescriptor fd);
}
Die Klasse FotoDescriptor hat nichts mit der Foto-Klasse gemeinsam. Man kann sie einfach mit den Parametern erzeugen, die die Factory benötigt. So hat man ein Objekt um die Parameter durch die gegend zu reichen und kann irgendwo eine Factory-Klasse haben, die dann das Foto erzeugt.
Wenn Du auf ungespeicherten Fotos schon arbeiten willst, wie auf gespeicherten, nur dass eben noch nicht alle Eigenschaften zur Verfügung stehen, dann solltest Du eine der beiden vorher vorgeschlagenen Lösungen nehmen und zwar genau so, wie dort beschrieben.
Der Zugriff auf die zusätzlichen Eigenschaften sollte dann wirklich über das referenzierte Objekt erfolgen. Versuche nicht, da wieder eine Vererbungshierarchie einzubauen, denn die Idee war ja gerade, diese loszuwerden und ein Foto durch zwei Objekte darzustellen, die jeweils einen Teil repräsentieren.
Eine Änderungsmöglichkeit wäre, die Methode "store" noch herauszulösen in eine extra Klasse:
FotoDB {
void store(FotoDescriptor f)
}
Diese würde dann das Foto speichern und dem FotoDescriptor das entsprechende Foto-Objekt hinzufügen. Das gleiche könnte man mit der Variante mit den Zustandsklassen realisieren.
Die Variante mit den Zustandsklassen hat übrigens dann einen Vorteil, wenn Du evtl. weitere Zustände brauchen könntest oder wenn Du für neue Fotos Daten brauchst, die Du für gespeicherte nicht mehr brauchst. Du könntest in FotoNew-Objekten z.B. HTTP-Parameter speichern. Das wäre glaube ich sogar die eleganteste Lösung. Allerdings nur, wenn Deine Problemstellung wirklich nach dieser Komplexität verlangt. Wenn es eine Factory-Klasse tut, sollte man dabei bleiben.
Grüße
Daniel