Hallo,
ist es möglich Klassen zur Laufzeit zu erweitern, also sie mit
gleichen Namen zu vererben?
class Test {
function tueEtwas() {}
}
class Test extends Test { //Soetwas möchtie ich bewerkstelligen
function michGabEsVorherNochNicht() {}
}
?>
Lukas Heidemann meinte:
> Hallo,
> ist es möglich Klassen zur Laufzeit zu erweitern, also sie mit
> gleichen Namen zu vererben?
>
>
> class Test {
> function tueEtwas() {}
> }
>
> class Test extends Test { //Soetwas möchtie ich bewerkstelligen
> function michGabEsVorherNochNicht() {}
> }
> ?>
Frage: Warum? Und woher weiss PHP, ob du mit $foo = new Test();
die Eltern- oder die abgeleitete Klasse meinst?
Gruß, Gregor
--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Lukas Heidemann wrote:
> ist es möglich Klassen zur Laufzeit zu erweitern, also sie mit
> gleichen Namen zu vererben?
>
>
> class Test {
> function tueEtwas() {}
> }
>
> class Test extends Test { //Soetwas möchtie ich bewerkstelligen
> function michGabEsVorherNochNicht() {}
> }
> ?>
Keine Ahnung obs das für PHP4 gibt. In PHP5 kann man sowas in die
Richtung mit __call machen. (Stichwort: magische Methoden)
Ließ Dir einfach mal das Manual dazu durch und entscheide selbst ob das
Deinen Ansprüchen genügt.
MfG, Ulf
Lukas Heidemann schrieb:
> ist es möglich Klassen zur Laufzeit zu erweitern, also sie mit
> gleichen Namen zu vererben?
Nein.
Meine Glaskugel sagt, dass du die Stichworte "Factory" und besonders
"Decorator" im OOP-Handbuch deiner Wahl nachschlagen solltest.
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Niels Braczek schrieb:
> Lukas Heidemann schrieb:
>
>> ist es möglich Klassen zur Laufzeit zu erweitern, also sie mit
>> gleichen Namen zu vererben?
>
> Nein.
>
> Meine Glaskugel sagt, dass du die Stichworte "Factory" und besonders
> "Decorator" im OOP-Handbuch deiner Wahl nachschlagen solltest.
Und um die Liste komplett zu machen:
http://pecl.php.net/package/classkit
Viel Spa0 beim evaluieren.
Gruß,
Torsten
Torsten Zühlsdorff schrieb:
> Und um die Liste komplett zu machen:
> http://pecl.php.net/package/classkit
Das gehört für mich in dieselbe Schublade wie eval(). Ich wage zu
behaupten, dass die Anforderung, Klassendefinition während der Laufzeit=
zu verändern, Folge eines Designfehlers ist.
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Hi,
Torsten Zühlsdorff wrote:
> Und um die Liste komplett zu machen:
> http://pecl.php.net/package/classkit
Das heißt mittlerweile runkit.
Grüße,
Alex
Niels Braczek wrote:
> Torsten Zühlsdorff schrieb:
>=20
>> Und um die Liste komplett zu machen:
>> http://pecl.php.net/package/classkit
>=20
> Das gehört für mich in dieselbe Schublade wie eval(). Ich wage zu
> behaupten, dass die Anforderung, Klassendefinition während der Laufze=
it
> zu verändern, Folge eines Designfehlers ist.
Das gilt aber im Gegensatz zu eval() lediglich für den Produktiveinsatz=
.
Wenn man classkit (bzw. besser, weil neuer runkit) ausschließlich für=
=20
die Entwicklung verwendet, kann das sehr hilfreich sein, insbesondere=20
bei php-cli. Wenn du einen daemon laufen hast, kann es je nach=20
Einsatzgebiet relativ nervig sein, diesen daemon bei der Entwicklung bei =
jeder Änderung an einer Klasse neustarten zu müssen. Dafür ist runk=
it=20
gut. Im späteren Produktiveinsatz würde ich dann auch die Finger von =
lassen. eval() dagegen erleichtert nicht mal die Entwicklung.
Grüße,
Alex
Niels Braczek schrieb:
> Torsten Zühlsdorff schrieb:
>
>> Und um die Liste komplett zu machen:
>> http://pecl.php.net/package/classkit
>
> Das gehört für mich in dieselbe Schublade wie eval(). Ich wage zu
> behaupten, dass die Anforderung, Klassendefinition während der Laufzeit
> zu verändern, Folge eines Designfehlers ist.
Wie gesagt: Ich habe es nur aufgeführt, damit die Liste komplett ist.
Allerdings stimme ich dir im zweiten Satz nicht zu. Diese Möglichkeit
ist - wie immer sinnvoll verwendet - eine gute Stütze in der generischen
Programmierung oder aber im Sparen unnötigen Quellcodes: Sprich immer
dann, wenn sich Abstraktionen ähneln.
Gruß,
Torsten
Alexander Schestag schrieb:
> Niels Braczek wrote:
>> Torsten Zühlsdorff schrieb:
>>=20
>>> Und um die Liste komplett zu machen:
>>> http://pecl.php.net/package/classkit
>>=20
>> Das gehört für mich in dieselbe Schublade wie eval(). Ich wage zu
>> behaupten, dass die Anforderung, Klassendefinition während der Laufz=
eit
>> zu verändern, Folge eines Designfehlers ist.
>=20
> Das gilt aber im Gegensatz zu eval() lediglich für den Produktiveinsa=
tz.=20
Ich ging auch vom Produktiv-Einsatz aus.
> Wenn man classkit (bzw. besser, weil neuer runkit) ausschließlich fü=
r=20
> die Entwicklung verwendet, kann das sehr hilfreich sein, insbesondere=20
> bei php-cli. Wenn du einen daemon laufen hast, kann es je nach=20
> Einsatzgebiet relativ nervig sein, diesen daemon bei der Entwicklung be=
i=20
> jeder Änderung an einer Klasse neustarten zu müssen. Dafür ist ru=
nkit=20
> gut.
Das mag sein, auf dem Spielplatz[tm] habe ich mich aber noch nicht
getummelt ;-)
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Torsten Zühlsdorff schrieb:
> Niels Braczek schrieb:
>> Torsten Zühlsdorff schrieb:
>>=20
>>> Und um die Liste komplett zu machen:
>>> http://pecl.php.net/package/classkit
>>=20
>> Das gehört für mich in dieselbe Schublade wie eval(). Ich wage zu
>> behaupten, dass die Anforderung, Klassendefinition während der Laufz=
eit
>> zu verändern, Folge eines Designfehlers ist.
>=20
> Wie gesagt: Ich habe es nur aufgeführt, damit die Liste komplett ist.=
>=20
> Allerdings stimme ich dir im zweiten Satz nicht zu. Diese Möglichkeit=
=20
> ist - wie immer sinnvoll verwendet - eine gute Stütze in der generisc=
hen=20
> Programmierung oder aber im Sparen unnötigen Quellcodes: Sprich immer=
=20
> dann, wenn sich Abstraktionen ähneln.
Und was ist der Vorteil gegenüber einem Decorator? Wie testet man
Klassen, die sich zur Laufzeit ändern (Unit-Tests)?
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Niels Braczek schrieb:
>> Allerdings stimme ich dir im zweiten Satz nicht zu. Diese Möglichkeit
>> ist - wie immer sinnvoll verwendet - eine gute Stütze in der generischen
>> Programmierung oder aber im Sparen unnötigen Quellcodes: Sprich immer
>> dann, wenn sich Abstraktionen ähneln.
>
> Und was ist der Vorteil gegenüber einem Decorator? Wie testet man
> Klassen, die sich zur Laufzeit ändern (Unit-Tests)?
Es geht doch darum eine Klasse zur Laufzeit neue Methoden und/oder
Attribute hinzufügen, zumindest hab ich das so vom OP verstanden. Da
hilft dir doch ein Decorator reichlich wenig, oder wie willst du den
hier anwenden?
mfg
Andreas
Andreas Eberhöfer schrieb:
> Es geht doch darum eine Klasse zur Laufzeit neue Methoden und/oder=20
> Attribute hinzufügen, zumindest hab ich das so vom OP verstanden. Da =
> hilft dir doch ein Decorator reichlich wenig, oder wie willst du den=20
> hier anwenden?
Um eine neue Methode hinzuzufügen (und zu benutzen), musst du sie ja
kennen. Die wird von einem Dekorator zur Verfügung gestellt, den man au=
f
das bestehende Objekt anwendet. Attribute lassen sich notfalls auch ohne
Eingriffe dynamisch hinzufügen.
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Niels Braczek schrieb:
> Andreas Eberhöfer schrieb:
>
>> Es geht doch darum eine Klasse zur Laufzeit neue Methoden und/oder
>> Attribute hinzufügen, zumindest hab ich das so vom OP verstanden. Da
>> hilft dir doch ein Decorator reichlich wenig, oder wie willst du den
>> hier anwenden?
>
> Um eine neue Methode hinzuzufügen (und zu benutzen), musst du sie ja
> kennen. Die wird von einem Dekorator zur Verfügung gestellt, den man auf
> das bestehende Objekt anwendet. Attribute lassen sich notfalls auch ohne
> Eingriffe dynamisch hinzufügen.
Das will der OP aber nicht. Er will eine Klasse haben die bestimmte
Methoden hat, nun will er eine oder mehrere neue Methode hinzufügen
_ohne_ das sich die Funktionalität der alten Methoden ändern. Dass das
mit normalen Sprachmittel nicht geht, steht außer Frage.
Als Workaround könnte man sich sowas mit __call basteln, wie Ulf bereits
geschrieben hat. Ich denke nur, dass sowas eh schlechtes Design ist und
man sich nochmal ganz genau überlegen sollte was man machen will.
mfg
Andreas
Andreas Eberhöfer schrieb:
> Das will der OP aber nicht. Er will eine Klasse haben die bestimmte=20
> Methoden hat, nun will er eine oder mehrere neue Methode hinzufügen=20
> _ohne_ das sich die Funktionalität der alten Methoden ändern. Dass =
das=20
> mit normalen Sprachmittel nicht geht, steht außer Frage.
Du irrst. Prinzip (mal in PHP4):
class OldClass
{
function std_method() {}
}
class OldClassDecorator
{
var $_old;
function OldClassDecorator( $oldClass )
{
$this->_old =3D $oldClass;
}
function std_method()
{
return $this->_old->std_method();
}
function new_method() {}
}
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Niels Braczek schrieb:
> class OldClass
> {
> function std_method() {}
> }
>
> class OldClassDecorator
> {
> var $_old;
>
> function OldClassDecorator( $oldClass )
> {
> $this->_old = $oldClass;
> }
>
> function std_method()
> {
> return $this->_old->std_method();
> }
>
> function new_method() {}
> }
Könntest du dir mal die Mühe machen, und dass erläutern? Für
Autodidakten, die (noch) nicht Informatik studiert haben, wird es hier
ab hier doch etwas abstrakt =)
Ich verstehe ja wohl den Hintergedanken der ganzen Sache, aber nicht
direkt, was da passiert und vor allem, wo ich sowas gebrauchen kann ...
Gruß,
Habbo
Jan Habbo Brüning wrote:
> Niels Braczek schrieb:
>> class OldClass
>> {
>> function std_method() {}
>> }
>>
>> class OldClassDecorator
>> {
>> var $_old;
>>
>> function OldClassDecorator( $oldClass )
>> {
>> $this->_old = $oldClass;
>> }
>>
>> function std_method()
>> {
>> return $this->_old->std_method();
>> }
>>
>> function new_method() {}
>> }
>
> Könntest du dir mal die Mühe machen, und dass erläutern? Für
> Autodidakten, die (noch) nicht Informatik studiert haben, wird es hier
> ab hier doch etwas abstrakt =)
>
> Ich verstehe ja wohl den Hintergedanken der ganzen Sache, aber nicht
> direkt, was da passiert und vor allem, wo ich sowas gebrauchen kann
> ...
Er hat eine Klasse OldClass, diese verfügt über eine Methode die
std_method() heisst - was die macht spielt erstmal keine Rolle. Diese Klasse
soll um die Methode new_method() erweitert werden, dazu baut er eine zweite
Klasse den Decorator OldClassdecorator.
Im Konstruktor des Decorators übergibt er ihm eine Instanz der alten Klasse
OldClass. Der Decorator kapselt jetzt sozusagen das Objekt der alten Klasse.
vorher:
OldClass
\----std_method()
nachher:
OldClassDecorator
\----OldClass
\----std_method()
damit er OldClassDecorator->std_method() benutzen kann, braucht er nun eine
Methode in OldClassDecorator, die die Methode std_method() von OldClass
aufruft und es liegt auf der Hand, dass die den selben Namen bekommt, wenn
sie das selbe machen soll.
jetzt:
OldClassDecorator
\----OldClass
\----std_method()
\----std_method()->OldClass->std_method()
und jetzt erweitert er die Decorator Klasse um eine neue Methode.
neu:
OldClassDecorator
\----OldClass
\----std_method()
\----std_method()->OldClass->std_method()
\----new_method()
C'est ca.
Johannes
PS: Ein Anwendungsbeispiel fällt mir jetzt leider aus dem Stehgreif nicht
ein.
Johannes Mueller schrieb:
> [ ... nette Erklärung zu Niels Dekorator ... ]
Alles klar, dann habe ich es doch richtig verstanden. Es wird also nur
eine Art "Mantel" um die alte Klasse gebildet und diese nicht wirklich
um eine Methode erweitert.
Vielleicht hat Niels selbst dann ja noch das fehlende Anwendungsbeispiel
für den realen Einsatz :)
Gruß,
Habbo
..oO(Johannes Mueller)
>[Decorator Pattern]
>
>PS: Ein Anwendungsbeispiel fällt mir jetzt leider aus dem Stehgreif nicht
>ein.
Ein klassisches Beispiel in der Literatur ist eine grafische
Benutzeroberfläche, bei welcher einem beliebigen grafischen Objekt
weitere "Verzierungen" wie Rahmen oder Scrollbalken hinzugefügt werden,
ohne die eigentliche Klasse anpassen zu müssen. Die Rahmen- und
Scrollbalken-Klassen stellen dabei lediglich eine Art Container dar,
welche das eigentliche Inhaltsobjekt beinhalten und um weitere
Funktionen ergänzen.
Eine etwas konkretere Anwendung ist z.B. meine persönliche Datenbank-
Klasse, welche einen Wrapper um PDO darstellt. Eine Instanz dieser
Klasse enthält selbst ein PDO-Objekt (welches somit durch meine Klasse
"dekoriert" und erweitert wird) und reicht sämtliche Methodenaufrufe via
__call() direkt an dieses durch, mit Ausnahme der query()-Methode. Diese
schreibt zuerst die auszuführende DB-Anfrage ins Logfile, bevor sie an
das eigentliche PDO-Objekt weitergeleitet und ausgeführt wird.
Micha
Michael Fesser schrieb:
> Eine etwas konkretere Anwendung ist z.B. meine persönliche Datenbank-
> Klasse, welche einen Wrapper um PDO darstellt. Eine Instanz dieser
> Klasse enthält selbst ein PDO-Objekt (welches somit durch meine Klasse
> "dekoriert" und erweitert wird) und reicht sämtliche Methodenaufrufe via
> __call() direkt an dieses durch, mit Ausnahme der query()-Methode. Diese
> schreibt zuerst die auszuführende DB-Anfrage ins Logfile, bevor sie an
> das eigentliche PDO-Objekt weitergeleitet und ausgeführt wird.
Lustiger Weise habe ich mir selbst exakt den gleichen Wrapper für PDO
gebastelt. Theoretische Ansätze erscheinen immer viel logischer, wenn
man merkt, dass man sie unerkannt bereits seit geraumer Zeit im Einsatz
hat ... :-)
Gruß,
Habbo
Jan Habbo Brüning schrieb:
> Johannes Mueller schrieb:
>> [ ... nette Erklärung zu Niels Dekorator ... ]
>=20
> Alles klar, dann habe ich es doch richtig verstanden. Es wird also nur =
> eine Art "Mantel" um die alte Klasse gebildet und diese nicht wirklich =
> um eine Methode erweitert.
>=20
> Vielleicht hat Niels selbst dann ja noch das fehlende Anwendungsbeispie=
l=20
> für den realen Einsatz :)
Nicht bei der Hand. Johannes' Erläuterungen waren recht ausführlich u=
nd
treffend. Ich wüsste nicht, warum man neue Methoden hinzufügen könn=
en
wollte; normalerweise werden Dekoratoren nur[tm] dafür verwendet, das
Verhalten bestehender Methoden zu modifizieren (wie das erwähnte
Query-Logging).
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Niels Braczek schrieb:
>>>> Und um die Liste komplett zu machen:
>>>> http://pecl.php.net/package/classkit
>>> Das gehört für mich in dieselbe Schublade wie eval(). Ich wage zu
>>> behaupten, dass die Anforderung, Klassendefinition während der Laufzeit
>>> zu verändern, Folge eines Designfehlers ist.
>> Das gilt aber im Gegensatz zu eval() lediglich für den Produktiveinsatz.
>
> Ich ging auch vom Produktiv-Einsatz aus.
Das ändert nichts ;)
>> Wenn man classkit (bzw. besser, weil neuer runkit) ausschließlich für
>> die Entwicklung verwendet, kann das sehr hilfreich sein, insbesondere
>> bei php-cli. Wenn du einen daemon laufen hast, kann es je nach
>> Einsatzgebiet relativ nervig sein, diesen daemon bei der Entwicklung bei
>> jeder Änderung an einer Klasse neustarten zu müssen. Dafür ist runkit
>> gut.
>
> Das mag sein, auf dem Spielplatz[tm] habe ich mich aber noch nicht
> getummelt ;-)
Achso. Das "Blup-Phänomen". :P
Sollte ich irgendwann mal mein Buch zum Thema "Praktische Möglichkeiten
und Konzepte generativer Programmierung am Beispiel von PHP", werde ich
es dir gerne ausleihen.
Das Problem daran ist, dass man bei der generativen Programmierung
unterscheidet, ob man den Code für der Ausführung/Kompilierung erstellt
oder während der Laufzeit. Ersteres ist sehr einfach in PHP. Zweiteres
nur über diverse Tricksereien. *Seufz*
Gruß,
Torsten
Niels Braczek schrieb:
> Torsten Zühlsdorff schrieb:
>> Niels Braczek schrieb:
>>> Torsten Zühlsdorff schrieb:
>>>
>>>> Und um die Liste komplett zu machen:
>>>> http://pecl.php.net/package/classkit
>>> Das gehört für mich in dieselbe Schublade wie eval(). Ich wage zu
>>> behaupten, dass die Anforderung, Klassendefinition während der Laufzeit
>>> zu verändern, Folge eines Designfehlers ist.
>> Wie gesagt: Ich habe es nur aufgeführt, damit die Liste komplett ist.
>>
>> Allerdings stimme ich dir im zweiten Satz nicht zu. Diese Möglichkeit
>> ist - wie immer sinnvoll verwendet - eine gute Stütze in der generischen
>> Programmierung oder aber im Sparen unnötigen Quellcodes: Sprich immer
>> dann, wenn sich Abstraktionen ähneln.
>
> Und was ist der Vorteil gegenüber einem Decorator? Wie testet man
> Klassen, die sich zur Laufzeit ändern (Unit-Tests)?
Es gibt verschiedene Vorteile:
1. Man verzichtet auf das Wissen der konkreten Implementation zur Zeit
der Erstellung des Quellcodes.
Wenn man davon ausgeht, dass der Dekorator händisch geschrieben wird,
muß dieser auch händisch im konkreten Applikationsdesign implementiert
und eingebunden werden.
Bei einer generativen Erstellung oder Manipulation der Klasse wird nur
die Kenntnis der Klasse verlangt. Das reduziert zum einen die
Abhängigkeiten im Design und ermöglicht, dass das konkrete Wissen über
die derzeitige Implementation der Klasse nur in sehr beschränkten Teilen
der Applikation vorhanden sein muß. Das hat desweiteren den Vorteil,
dass wenn man eben diese Teile entfernt, es keinerlei Einfluß auf andere
Applikationsteile gibt (was z.b. Inversion of Control zu verhindern
versucht).
2. Man kann die konkrete Struktur, die häufig auf Daten basiert,
auslagern. Viele Klassen basieren auf Daten. Es ist so z.b. möglich,
dass wenn neue Daten auftreten, dafür neue Methoden von den Daten
abgeleitet werden können.
3. Hochverfügbarkeitsapplikationen können so zur Laufzeit erweitert
werden. Vor vielen vielen Jahren war es gängig, dass ein Programm zur
Laufzeit lediglich den neuen Code nachlädt und dabei schlicht weiter
läuft. Heutzutage muß aber nahezu immer alles neu
kompiliert/interpretiert werden. Und es gibt Applikationen, bei denen
das "ungünstig" ist.
[to be continued]
Das Testen ist ähnlich wie dem generieren von Unit-Tests. Man fügt
Methoden auf Basis von einem (dynamisch vorhandenen) Wissen hinzu bzw.
manipuliert sie. Das Wissen um deren Funktionalität ist damit auch
vorhanden - wenn auch nicht zwangsweise beim Programmierer. Auf Basis
dieser Funktionalität lassen sich natürlich auch die notwendigen Tests
ableiten und generieren.
Gruß,
Torsten
Niels Braczek schrieb:
> Andreas Eberhöfer schrieb:
>
>> Das will der OP aber nicht. Er will eine Klasse haben die bestimmte
>> Methoden hat, nun will er eine oder mehrere neue Methode hinzufügen
>> _ohne_ das sich die Funktionalität der alten Methoden ändern. Dass das
>> mit normalen Sprachmittel nicht geht, steht außer Frage.
>
> Du irrst. Prinzip (mal in PHP4):
>
> class OldClass
> {
> function std_method() {}
> }
>
> class OldClassDecorator
> {
> var $_old;
>
> function OldClassDecorator( $oldClass )
> {
> $this->_old = $oldClass;
> }
>
> function std_method()
> {
> return $this->_old->std_method();
> }
>
> function new_method() {}
> }
Das ist übrigens eher ein Strategy-Pattern als ein Decorator. Bei einem
Decorator würde std_method im OldClassDecorator noch selbst irgendwas
machen, z.B. Vor und Nachbedingungen prüfen oder Logging hinzufügen. Es
wird also die Methode std_method mit neuer Funktionalität dekoriert. Bei
einem Strategy-Pattern geht es darum einen Algorithmus auszulagern, da
es vielleicht mehrere gibt. So spontan fällt mir nur LayoutManger in GUI
ein. Je nachdem wie der LayoutManager implementiert ist werden die
Komponenten z.B. Spalten oder Zeilenweise angezeigt.
Soviel dazu. Du hast recht, damit könnte man indirekt OldClass neue
Methoden hinzufügen, aber was ist denn der Vorteil gegenüber wenn ich
einfach class NewClass extends OldClass schreibe?
mfg
Andreas
Niels Braczek schrieb:
> Andreas Eberhöfer schrieb:
>
>> Das will der OP aber nicht. Er will eine Klasse haben die bestimmte
>> Methoden hat, nun will er eine oder mehrere neue Methode hinzufügen
>> _ohne_ das sich die Funktionalität der alten Methoden ändern. Dass das
>> mit normalen Sprachmittel nicht geht, steht außer Frage.
>
> Du irrst. Prinzip (mal in PHP4):
Das würde allerdings nur dann Stimmen, wenn mit "eine Klasse" eine
"beliebige Klasse" gemeint ist und nicht die Erweiterung einer
"konkreten Klasse" :)
Gruß,
Torsten
Andreas Eberhöfer schrieb:
> Soviel dazu. Du hast recht, damit könnte man indirekt OldClass neue=20
> Methoden hinzufügen, aber was ist denn der Vorteil gegenüber wenn i=
ch=20
> einfach class NewClass extends OldClass schreibe?
Der einzige Vorteil liegt darin, dass man ein bereits instantiiertes
Objekt nachträglich mit neuen Methoden versehen kann.
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Torsten Zühlsdorff schrieb:
> Niels Braczek schrieb:
>> Und was ist der Vorteil gegenüber einem Decorator? Wie testet man
>> Klassen, die sich zur Laufzeit ändern (Unit-Tests)?
>=20
> Es gibt verschiedene Vorteile:
Danke für den Einblick.
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Niels Braczek schrieb:
> Andreas Eberhöfer schrieb:
>=20
>> Das will der OP aber nicht. Er will eine Klasse haben die bestimmte=20
>> Methoden hat, nun will er eine oder mehrere neue Methode hinzufügen =
>> _ohne_ das sich die Funktionalität der alten Methoden ändern. Dass=
das=20
>> mit normalen Sprachmittel nicht geht, steht außer Frage.
>=20
> Du irrst. Prinzip (mal in PHP4):
>=20
> class OldClass
> {
> function std_method() {}
> }
>=20
> class OldClassDecorator
> {
> var $_old;
>=20
> function OldClassDecorator( $oldClass )
> {
> $this->_old =3D $oldClass;
> }
>=20
> function std_method()
> {
> return $this->_old->std_method();
> }
>=20
> function new_method() {}
> }
Der Vollständigkeit halber führe ich hier mal wieder den "generischen=
Decorator" auf (diesmal "PHP5 only"):
class OldClassDecorator
{
protected $_old;
public function __construct(OldClass $oldClass)
{
$this->_old =3D $oldClass;
}
public function new_method() {}
// alles andere an OldClass weiterreichen
public function __call($name,$args)
{
return call_user_func_array(
array($this->_old,$name),
$args
);
}
}
Das erspart das nervige Wiederholen des gesamten Interfaces von OldClass.=
OLLi
--=20
"Wobei: Wenn man um 8 Uhr fliegt, kann man ja noch 'nen halben Tag
arbeiten."
[Nico, Flugplanung Barcelona]
Hallo,
> class Test extends Test { //Soetwas möchtie ich bewerkstelligen
Vielleicht hilft dir die Tatsache, dass jede Sub-Klasse auch immer vom
Typ der Super-Klasse ist?
class Super { ... }
class Child extends Super { ... }
$a = new Child();
function doSomething(Super $object) ==> Type Hint erfüllt
Vielleicht solltest du dir aber ein feines Buch über Objektorientierung,
im Speziellen OOP in PHP zulegen.
Thomas
Torsten Zühlsdorff wrote:
> Sollte ich irgendwann mal mein Buch zum Thema "Praktische Möglichkeiten
> und Konzepte generativer Programmierung am Beispiel von PHP",
[ ] finden?
[ ] schreiben?
Wenn Dus findest oder geschrieben hast würde ich mich auch mal dafür
interessieren wollen. :-z
MfG, Ulf
Ulf Kadner schrieb:
> Torsten Zühlsdorff wrote:
>
>> Sollte ich irgendwann mal mein Buch zum Thema "Praktische
>> Möglichkeiten und Konzepte generativer Programmierung am Beispiel von
>> PHP",
>
> [ ] finden?
> [X] schreiben?
>
> Wenn Dus findest oder geschrieben hast würde ich mich auch mal dafür
> interessieren wollen. :-z
Zum Fehlerlesen? :P
Ich hatte Niels und dich schon vorher auf meiner Liste möglicher
Interessenten. ;)
Gruß,
Torsten