Mailinglisten-Archive |
Konstantin Rekk wrote: > Dein Ansatz entspricht meiner Kenntnis nach nicht ganz dem OO-Ansatz, > Daten und Methoden zusammenzufassen und den Zugriff auf Daten zu kapseln, > in diesem Fall Bild ist eigenes Objekt mit eigenen Methoden, die Sichten oder > Schnittstellen für Zugriff von außen definieren, Service-Funktionen werden > als static implementiert! > > Darüberhinaus bieten sich viele Möglichkeiten in Abhängigkeit vom > konkreten Problem, gemeinsam ist der obere Ansatz. > wichtigste: > a) DATA wird erweitert um Funktionalitäten von DO, wird quasi DO Eher schlecht weil DO sehr umfangreich werden könnte. > b) DO Basisklasse mit Bilddaten als Membervariable und Basisfunktionen > (DATA ist in DO). Da hab ich das Problem das ich in DATA keine Funktionalität nutzen (bzw darauf zugreifen) kann. > c) DO kennt Bilddaten (referenz), hier aber nicht zu empfehlen, wegen dem > oberen, dies nur geeignet wenn DATA eine eigene Funktionalität besitzt, und > nicht nur über DO verarbeitet wird. So läufts momentan. Ich denke ich werde aus DATA die Methoden extrahieren und in eine eigene Klasse packen. Es werden sowieso noch Abwandlungen von DATA entstehen, so könnte ich dann zu jedem Ableger eine eigene Funktionalität zur Laufzeit laden. Was zwar wieder dir Usability killt aber ist halt sauberer. > d) .... > > Hier könnte sich auch > das Factory, oder auch Strategy-Pattern anbieten, wenn du den > Verarbeitungsmodus zur Laufzeit bestimmen willst. Vielleicht wäre ein Decorator-Pattern geeigneter für mich.
php::bar PHP Wiki - Listenarchive