phpbar.de logo

Mailinglisten-Archive

[php] &$objekt == *RECURSION*

[php] &$objekt == *RECURSION*

"patrick müller (aka elias)" ghostwwinside at gmx.net
Die Apr 20 15:28:47 CEST 2004


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