Die Diskussion um das Type-Hinting mit NULL-Pointern hat mich wieder
an etwas erinnert, was ich gerne loesen wuerde: es kommt immer wieder
vor, dass auf Methoden von Objekten, die auch den Wert NULL enthalten
koennen, zugegriffen wird. Ueblicherweise (also meist per Konvention)
ist es so, dass dem NULL-Objekt auch ein return value NULL der (nicht)
aufgerufenen Methode entspraeche. Bloss klappt das eben nicht, daher
schreibe ich:

| if (is_null($obj)) $result = NULL;
| else $result = $obj->method();

Das kann, wenn es haeufiger (und das tut es in manchen Programmteilen)
oder gar mehrstufig verschachtelt vorkommt, gleichermassen
unuebersichtlich wie laestig werden und ist in meinen Augen letztlich
ueberfluessig - nur ist mir kein Weg bekannt, wie ich den beim Aufruf
von

| $a = NULL;
| $b = $a->method();

aufretenden Fehler abfangen und durch das Ergebnis NULL ersetzen
koennte. Geht das vielleicht irgendwie? Alle moeglichen Dinge faengt PHP
ab, obwohl ich es gar nicht haben will (Funktionsaufrufe mit mehr
Parametern, als verarbeitet werden, sind da so ein Beispiel), aber hier
scheint es offenbar weder gewollt noch ueberhaupt machbar...

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Freiheit in der Agonie des Glücks: Stefan!
(Sloganizer)

Stefan Froehlich schrieb:
> Die Diskussion um das Type-Hinting mit NULL-Pointern hat mich wieder
> an etwas erinnert, was ich gerne loesen wuerde: es kommt immer wieder
> vor, dass auf Methoden von Objekten, die auch den Wert NULL enthalten
> koennen, zugegriffen wird. Ueblicherweise (also meist per Konvention)
> ist es so, dass dem NULL-Objekt auch ein return value NULL der (nicht)
> aufgerufenen Methode entspraeche. Bloss klappt das eben nicht, daher
> schreibe ich:
>
> | if (is_null($obj)) $result = NULL;
> | else $result = $obj->method();
>
> Das kann, wenn es haeufiger (und das tut es in manchen Programmteilen)
> oder gar mehrstufig verschachtelt vorkommt, gleichermassen
> unuebersichtlich wie laestig werden und ist in meinen Augen letztlich
> ueberfluessig

Wenn es dir nur um den Stil geht und nicht um Performance kannst du das
ja in eine Funktion auslagern.

function callMethodOrNull($obj) {
return is_null($obj) ? NULL : $obj->method();
}

$obj = new Foo();
$result = Method($obj);

$obj = NULL;
$result = Method($obj);

Und wenn es für verschiedene Methoden funktionieren soll, eben noch ein
2. Parameter.

regards,
Jens

Stefan Froehlich schrieb:

> Das kann, wenn es haeufiger (und das tut es in manchen Programmteilen)
> oder gar mehrstufig verschachtelt vorkommt, gleichermassen
> unuebersichtlich wie laestig werden und ist in meinen Augen letztlich
> ueberfluessig - nur ist mir kein Weg bekannt, wie ich den beim Aufruf
> von
>
> | $a =3D NULL;
> | $b =3D $a->method();
>
> aufretenden Fehler abfangen und durch das Ergebnis NULL ersetzen
> koennte. Geht das vielleicht irgendwie?

Was hältst du von (ungetestete Idee)

class NullObject
{
public function __call( $m, $a ) { return null; }
public function __get( $v ) { return null; }
public function __set() { return null; }
}

?

Statt

> | $a =3D NULL;
> | $b =3D $a->method();

dann einfach

$a =3D new NullObject;
$b =3D $a->method();

MfG
Niels

--
| 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 =
|
------------------------------------------------------------ ------

Stefan Froehlich schrieb:
> Die Diskussion um das Type-Hinting mit NULL-Pointern hat mich wieder
> an etwas erinnert, was ich gerne loesen wuerde: es kommt immer wieder
> vor, dass auf Methoden von Objekten, die auch den Wert NULL enthalten
> koennen, zugegriffen wird. Ueblicherweise (also meist per Konvention)
> ist es so, dass dem NULL-Objekt auch ein return value NULL der (nicht)
> aufgerufenen Methode entspraeche. Bloss klappt das eben nicht, daher
> schreibe ich:
>
> | if (is_null($obj)) $result = NULL;
> | else $result = $obj->method();
>
> Das kann, wenn es haeufiger (und das tut es in manchen Programmteilen)
> oder gar mehrstufig verschachtelt vorkommt, gleichermassen
> unuebersichtlich wie laestig werden und ist in meinen Augen letztlich
> ueberfluessig - nur ist mir kein Weg bekannt, wie ich den beim Aufruf
> von
>
> | $a = NULL;
> | $b = $a->method();
>
> aufretenden Fehler abfangen und durch das Ergebnis NULL ersetzen
> koennte. Geht das vielleicht irgendwie? Alle moeglichen Dinge faengt PHP
> ab, obwohl ich es gar nicht haben will (Funktionsaufrufe mit mehr
> Parametern, als verarbeitet werden, sind da so ein Beispiel), aber hier
> scheint es offenbar weder gewollt noch ueberhaupt machbar...

Ich sehe keinen Weg, und als ich angefangen habe, E_NOTICE-sicher zu
programmieren, habe ich genau darüber gestöhnt, die ganzen issets,
array_has_key und so weiter.

Allerdings hat mich das dazu gebracht, vorausschauender zu
programmieren; ich meine damit, dass es gar nicht mehr so häufig nötig
ist, dass ein Wert einmal ein Objekt oder aber auch NULL sein kann.

Ein Beispiel: ich verwende für ein Widget das Decorator-Pattern. Ich
könnte dem Constructor des Widgets optional den Decorator mitgeben:

function __construct($name, WidgetDecorator $decorator=NULL) {
if($decorator===NULL) {
//blah
}
}

Tatsächlich werde ich den Decorator selten gebrauchen. Alternative:
function __construct($name) {
$this->decorator = new WidgetDecorator();
}
function __getDecorator() {
return $this->decorator();
}
function drawWidget() {
// tue irgendwas mit WidgetDecorator();
}

Da Objektkopien seit PHP5 immer Referenzen sind, kann ich mir den
Decorator im Benötigungsfalle rausziehen und ihn nutzen; der Decorator
ist so oder so vorhanden, so dass es in drawWidget keinen Unterschied
mehr macht, ob ich ihn genutzt habe oder nicht, ich habe mir ein
if(is_null($decorator)) vom Hals geschafft und die Parameterzahl des
Constructors klein gehalten. Denn ich mag das nicht, wenn die Mehrheit
der Parameter beim Aufruf NULL ist, weil ich den 5. optionalen Parameter
setzen muss:

$widget = new Widget("irgendwas", NULL, NULL, NULL, "400");

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/
Ansonsten:
http://www.php-faq.de/q/q-newsgroup-wie-helfen.html

>
> Was hältst du von (ungetestete Idee)
>
> class NullObject
> {
> public function __call( $m, $a ) { return null; }
> public function __get( $v ) { return null; }
> public function __set() { return null; }
> }
>
> ?
>
> Statt
>
>> | $a = NULL;
>> | $b = $a->method();
>
> dann einfach
>
> $a = new NullObject;
> $b = $a->method();

Bitte nicht. Ich glaube, dass ist eine exzellente Möglichkeit, sich
schwer zu findende Bugs einzuladen.
Ausserdem kannst Du NullObject ja nicht als default-Wert bei einem Type
Hinting angeben (das war ja der Auslöser)

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/
Ansonsten:
http://www.php-faq.de/q/q-newsgroup-wie-helfen.html

Hadanite Marasek schrieb:

>> class NullObject
>> {
>> public function __call( $m, $a ) { return null; }
>> public function __get( $v ) { return null; }
>> public function __set() { return null; }
>> }

> Ich glaube, dass ist eine exzellente Möglichkeit, sich
> schwer zu findende Bugs einzuladen.

Ja, aber nur dann, wenn man das Ding nicht korrekt[tm] einsetzt.

> Ausserdem kannst Du NullObject ja nicht als default-Wert bei einem Type=

> Hinting angeben (das war ja der Auslöser)

Das ist klar. Ich dachte mir das so:

function foo(ObjectType $value=3DNULL)
{
if ( is_null( $value ) ) {
$value =3D new NullObject;
}
// Hier kann jetzt fortgefahren werden, ohne bei jedem
// Zugriff eine erneute Prüfung durchzuführen
...
}

Durch die lokale Instantiierung bleibt das Konstrukt überschau- und
debugbar.

MfG
Niels

--
| 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 =
|
------------------------------------------------------------ ------

On Fri, 11 Jan 2008 01:57:42 +0100 Hadanite Marasek wrote:
> | $a = NULL;
> | $b = $a->method();

> Ich sehe keinen Weg, und als ich angefangen habe, E_NOTICE-sicher zu
> programmieren, habe ich genau darüber gestöhnt, die ganzen issets,
> array_has_key und so weiter.

> Allerdings hat mich das dazu gebracht, vorausschauender zu
> programmieren;

Deine Beispiele sind durchaus ok und tragen dazu bei, das Problem
zu reduzieren - beim Aufruf von Methoden ist das relativ einfach.

Vorrangig aergere ich mich im Zusammenhang mit Templates. Vorher(TM)
gab es da verschachtelte Arrays, deren Komponenten existieren konnten
oder nicht. Die Templates enthielten dann die notwendige Intelligenz,
das passend darzustellen: manchmal war dafuer eine Abfrage notwendig,
aber oft reichte eben einfach eine Ausgabe aus; wo nichts war, brauchte
auch nichts ausgegeben werden. So schrieb:

| $data['address']['person']['email']['publickey']

....den entsprechenden Schluessel auf eine Seite mit allgemeinen
Personendaten, bzw. liess das Feld halt leer, wenn es keinen gab.

Mit Objekten ist zwar auf der einen Seite nun alles viel eleganter,
da statt einer komplizierten Array-Definition nur noch ein Objekt mit
bereits dokumentierter Infrastruktur uebergeben wird. Auf der anderen
Seite bin ich (oder schlimmer: jemand, der mit den Templates
weiterarbeitet) aber nun gezwungen, an der Stelle, wo
Address()->Person()->Email()->PublicKey() vorkommt, _jede_ einzelne
Komponente davon auf Existenz abzufragen. Das empfinde ich innerhalb
eines Templates einfach nur als grausam, fehleranfaellig und eben
voellig unnotwendig.

> Denn ich mag das nicht, wenn die Mehrheit der Parameter beim Aufruf
> NULL ist, weil ich den 5. optionalen Parameter setzen muss:

> $widget = new Widget("irgendwas", NULL, NULL, NULL, "400");

Da bin ich vollkommen bei Dir. So etwas mache ich nur, wenn die
Parameter eindeutig absteigende Wichtigkeit haben, d.h. ich:

| new Widget("irgendwas");
| new WIdget("irgendwas", 400);
| new WIdget("irgendwas", 400, "abcde");

....schreiben kann.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan - der grünste Werbegag seit der Steinzeit.
(Sloganizer)

Hadanite Marasek schrieb:
> Ausserdem kannst Du NullObject ja nicht als default-Wert bei einem Type
> Hinting angeben (das war ja der Auslöser)

Wenn ein NULL Wert zu Problemen führen würde, sollte man ihn vielleicht
einfach nicht als Default Wert aufführen?

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Stefan Froehlich schrieb:

> | if (is_null($obj)) $result = NULL;
> | else $result = $obj->method();

In diesem Fall gefällt mir:

$result = NULL;
if ($obj){ $result = $obj->method();}

besser. Weil $result auf jeden Fall initialisiert wird. Bei deinem Code
könnte ein Parser auf die Idee kommen das $result unter Umständen,
eventuell vielleicht nicht vorhanden sein könnte.

> Das kann, wenn es haeufiger (und das tut es in manchen Programmteilen)
> oder gar mehrstufig verschachtelt vorkommt, gleichermassen
> unuebersichtlich wie laestig werden und ist in meinen Augen letztlich
> ueberfluessig - nur ist mir kein Weg bekannt, wie ich den beim Aufruf
> von
>
> | $a = NULL;
> | $b = $a->method();

in diesem Fall geht:

$obj= NULL;
$result = $obj ? $obj->method() : null;

oder so ähnlich. Auch hier wird $result auf jeden Fall initialisiert.

Harald Stowasser schrieb:
> Stefan Froehlich schrieb:

>> | if (is_null($obj)) $result = NULL;
>> | else $result = $obj->method();

> $result = NULL;
> if ($obj){ $result = $obj->method();}

> besser. Weil $result auf jeden Fall initialisiert wird. Bei deinem Code
> könnte ein Parser auf die Idee kommen das $result unter Umständen,
> eventuell vielleicht nicht vorhanden sein könnte.

Ein derart kaputter Parser könnte aber auch auf ganz andere Ideen
kommen. Welcher Parser sollte das sein?

--
"Faulheit ist die Wurzel allen Fortschritts!"
(Inhalt eines Knallbonbons, 2002)

Hadanite Marasek schrieb:
> Stefan Froehlich schrieb:

>> | if (is_null($obj)) $result = NULL;
>> | else $result = $obj->method();

>> Das kann, wenn es haeufiger (und das tut es in manchen Programmteilen)
>> oder gar mehrstufig verschachtelt vorkommt, gleichermassen
>> unuebersichtlich wie laestig werden und ist in meinen Augen letztlich
>> ueberfluessig - nur ist mir kein Weg bekannt, wie ich den beim Aufruf
>> von

>> | $a = NULL;
>> | $b = $a->method();

>> aufretenden Fehler abfangen und durch das Ergebnis NULL ersetzen
>> koennte. Geht das vielleicht irgendwie? Alle moeglichen Dinge faengt PHP
>> ab, obwohl ich es gar nicht haben will (Funktionsaufrufe mit mehr
>> Parametern, als verarbeitet werden, sind da so ein Beispiel), aber hier
>> scheint es offenbar weder gewollt noch ueberhaupt machbar...

> Ein Beispiel: ich verwende für ein Widget das Decorator-Pattern. Ich
> könnte dem Constructor des Widgets optional den Decorator mitgeben:
>
> function __construct($name, WidgetDecorator $decorator=NULL) {
> if($decorator===NULL) {
> //blah
> }
> }
>
> Tatsächlich werde ich den Decorator selten gebrauchen. Alternative:
> function __construct($name) {
> $this->decorator = new WidgetDecorator();
> }
> function __getDecorator() {
> return $this->decorator();
> }
> function drawWidget() {
> // tue irgendwas mit WidgetDecorator();
> }

Ich würde das ggf. so verbinden:

function __construct($name, WidgetDecorator $decorator = null) {
if(is_null($decorator)) {
$decorator = new DefaultWidgetDecorator();
}

$this->decorator = $decorator;
}

> Da Objektkopien seit PHP5 immer Referenzen sind, kann ich mir den
> Decorator im Benötigungsfalle rausziehen und ihn nutzen; der Decorator
> ist so oder so vorhanden, so dass es in drawWidget keinen Unterschied
> mehr macht, ob ich ihn genutzt habe oder nicht, ich habe mir ein
> if(is_null($decorator)) vom Hals geschafft und die Parameterzahl des
> Constructors klein gehalten. Denn ich mag das nicht, wenn die Mehrheit
> der Parameter beim Aufruf NULL ist, weil ich den 5. optionalen Parameter
> setzen muss:
>
> $widget = new Widget("irgendwas", NULL, NULL, NULL, "400");

Man könnte bei vielen verschiedenen Parametern alternativ auch ein
assoz. Array übergeben oder das Objekt später konfigurieren.

$widget = new Widget('irgendwas');
$widget->setFoo(400);

--
"Faulheit ist die Wurzel allen Fortschritts!"
(Inhalt eines Knallbonbons, 2002)

Hadanite Marasek schrieb:

> Ein Beispiel: ich verwende für ein Widget das Decorator-Pattern. Ich =

> könnte dem Constructor des Widgets optional den Decorator mitgeben:
>
> function __construct($name, WidgetDecorator $decorator=3DNULL) {
> if($decorator=3D=3D=3DNULL) {
> //blah
> }
> }
>
> Tatsächlich werde ich den Decorator selten gebrauchen. Alternative:
> function __construct($name) {
> $this->decorator =3D new WidgetDecorator();
> }
> function __getDecorator() {
> return $this->decorator();
> }
> function drawWidget() {
> // tue irgendwas mit WidgetDecorator();
> }

Das ist aber doch kein Decorator. Der würde so angewendet:

$widget =3D new Widget();
$widget =3D new WidgetDecorator( $widget );

(http://de.wikipedia.org/wiki/Decorator)

MfG
Niels

--
| 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 =
|
------------------------------------------------------------ ------

>
> Das ist aber doch kein Decorator. Der würde so angewendet:
>
> $widget = new Widget();
> $widget = new WidgetDecorator( $widget );
>
> (http://de.wikipedia.org/wiki/Decorator)

Ah, dann danke für die Korrektur.

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/
Ansonsten:
http://www.php-faq.de/q/q-newsgroup-wie-helfen.html

> Ich würde das ggf. so verbinden:
>
> function __construct($name, WidgetDecorator $decorator = null) {
> if(is_null($decorator)) {
> $decorator = new DefaultWidgetDecorator();
> }
>
> $this->decorator = $decorator;
> }

Genau das will ich ja vermeiden. Wenn ich einen Parameter dazu haben
will, habe ich ein Problem. Methodenaufrufe wie methode("irks", NULL,
CONSTANT) mag ich nicht, gibts in PHP schon genug.

> Man könnte bei vielen verschiedenen Parametern alternativ auch ein
> assoz. Array übergeben oder das Objekt später konfigurieren.

Das finde ich noch schlimmer. Entweder besteht dann der Konstruktor
überwiegend daraus, die Gültigkeit des Arrays zu überprüfen, oder ich
überprüfe nicht - mit absehbaren Folgen. Anstelle eines assoziativen
Arrays immer ein Objekt!


--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/
Ansonsten:
http://www.php-faq.de/q/q-newsgroup-wie-helfen.html

Hadanite Marasek schrieb:
>> Ich würde das ggf. so verbinden:

>> function __construct($name, WidgetDecorator $decorator = null) {
>> if(is_null($decorator)) {
>> $decorator = new DefaultWidgetDecorator();
>> }
>>
>> $this->decorator = $decorator;
>> }

> Genau das will ich ja vermeiden. Wenn ich einen Parameter dazu haben
> will, habe ich ein Problem. Methodenaufrufe wie methode("irks", NULL,
> CONSTANT) mag ich nicht, gibts in PHP schon genug.

Du hast Probleme. Das Konzept der globalen Variablen könnte dir
vielleicht gefallen, dann brauchst du gar keine Parameter mehr. Wenn dir
meth('irgs', null, constant) nicht gefällt, dann solltest du die Methode
vielleicht intern umbauen. Aber das willst du wieder nicht, weil ja dann
in der Methode wieder "zu viel" erledigt wird.

>> Man könnte bei vielen verschiedenen Parametern alternativ auch ein
>> assoz. Array übergeben oder das Objekt später konfigurieren.
>
> Das finde ich noch schlimmer. Entweder besteht dann der Konstruktor
> überwiegend daraus, die Gültigkeit des Arrays zu überprüfen, oder ich
> überprüfe nicht - mit absehbaren Folgen.

Aha. Ich hatte bisher keine Probleme damit und der Konstruktor besteht
auch nicht nur daraus irgendwas zu prüfen.

public function __construct($opts) {
self::verifyOptions($opts);

$this->foo = $opts['foo'];
$this->bar = $opts['bar'];
}

> Anstelle eines assoziativen Arrays immer ein Objekt!

Ja, schöne Floskel. Und wie kriegst du die Daten dann wieder in das
Objekt, wenn du sie a) nicht mit dem Konstruktor übergeben willst, b)
keine assoz. Array willst und c) auch etwas dagegen hast, das Objekt
später zu konfigurieren? man rekursion

--
"Faulheit ist die Wurzel allen Fortschritts!"
(Inhalt eines Knallbonbons, 2002)

On Sun, 13 Jan 2008 10:44:27 +0100 Thomas Hamacher wrote:
> > Methodenaufrufe wie methode("irks", NULL, CONSTANT) mag ich nicht,
> > gibts in PHP schon genug.

> Wenn dir meth('irgs', null, constant) nicht gefällt, dann solltest du
> die Methode vielleicht intern umbauen. Aber das willst du wieder
> nicht, weil ja dann in der Methode wieder "zu viel" erledigt wird.

Es gibt einfach zu viele unterschiedliche Anwendungsfaelle. Manchmal
habe ich fuer eine Methode 5 Parameter, von denen meist nur 3 benoetigt
werden, aber nicht immer die gleichen. Arrays mag ich (aus Erfahrung)
auch nicht besonders, eine Objektklasse muesste u.U. eigens dafuer
geschaffen, sowie das Objekt befuellt und wieder gelesen werden.

Als angenehm wuerde ich die optionale(!) Moeglichkeit empfinden,
Funktionen und Methoden so aufzurufen:

| $x = meth(a = 'irgs', c= CONSTANT);

....aber das geht halt nicht. Meist helfe ich mir in den pathologischen
Faellen mit einer zweiten Methode, die als Wrapper der ersten arbeitet.
Hat natuerlich auch Fehlerpotential, aber IMHO ein geringeres.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Im siebten Himmel. Mit Stefan. Ein geziertes Vergnügen!
(Sloganizer)

>> Genau das will ich ja vermeiden. Wenn ich einen Parameter dazu haben
>> will, habe ich ein Problem. Methodenaufrufe wie methode("irks", NULL,
>> CONSTANT) mag ich nicht, gibts in PHP schon genug.
>
> Du hast Probleme. Das Konzept der globalen Variablen könnte dir
> vielleicht gefallen, dann brauchst du gar keine Parameter mehr. Wenn dir
> meth('irgs', null, constant) nicht gefällt, dann solltest du die Methode
> vielleicht intern umbauen. Aber das willst du wieder nicht, weil ja dann
> in der Methode wieder "zu viel" erledigt wird.

Hmm, ich glaub da habe ich mich undeutlich ausgedrückt. Was ich nicht
mag sind Methoden mit fünf Parametern, von denen vier optional sind; den
letzten will ich setzen und dann hab ich dreimal NULL drin.

>> Anstelle eines assoziativen Arrays immer ein Objekt!
>
> Ja, schöne Floskel. Und wie kriegst du die Daten dann wieder in das
> Objekt, wenn du sie a) nicht mit dem Konstruktor übergeben willst, b)
> keine assoz. Array willst und c) auch etwas dagegen hast, das Objekt
> später zu konfigurieren? man rekursion

Nun, ich will das Objekt ja dem Konstruktor des anderen übergeben. Ich
habe auch nichts dagegen, Objekte zu konfigurieren, nur teile ich gerne
Zuständigkeiten auf.

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/
Ansonsten:
http://www.php-faq.de/q/q-newsgroup-wie-helfen.html

Hadanite Marasek schrieb:
> Genau das will ich ja vermeiden. Wenn ich einen Parameter dazu haben
> will, habe ich ein Problem. Methodenaufrufe wie methode("irks", NULL,
> CONSTANT) mag ich nicht, gibts in PHP schon genug.

PHP hat nur wenig Methodenaufrufe, weil PHP sehr wenig Klassen besitzt.
Aus diesem Grunde wäre es nicht schlecht sich auf andere Möglichkeiten
zu beruhen.

Bei Konstruktoren würde ich immer nur die Dinge in die Parameterliste
setzen die _immer_ übergeben werden _müssen_ (Zum Beispiel beim Arbeiten
mit Dateien den Dateipfad). Alle anderen Angaben werden bei mir per
Setter Methoden gesetzt. Deswegen gibt es kein Konstruktor der mehr als
2-3 Parameter verlangt und die einzige Methode die darüber hinaus geht
ist die für Datenbankverbindung (Datenbank, Benutzername, Passwort,
Hostname, Port, da lässt sich nicht viel dran rütteln).

> Das finde ich noch schlimmer. Entweder besteht dann der Konstruktor
> überwiegend daraus, die Gültigkeit des Arrays zu überprüfen, oder ich
> überprüfe nicht - mit absehbaren Folgen. Anstelle eines assoziativen
> Arrays immer ein Objekt!

Objekte die nur den Grund haben Einstellungen weiterzugeben halte ich
für unsinnig... Aber ist sicherlich Geschmackssache. Bei vielen
boolschen Angaben (bei der GUI Entwicklung sehr gebräuchlich) kann man
ja Flags verwenden.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Hadanite Marasek schrieb:

> Nun, ich will das Objekt ja dem Konstruktor des anderen übergeben. Ic=
h
> habe auch nichts dagegen, Objekte zu konfigurieren, nur teile ich gerne=

> Zuständigkeiten auf.

Was für ein Fall ist das, wo du dem Konstruktor optional ein Objekt
übergeben musst? Das hört sich für mich erstmal nach suboptimaler
Architektur an...

MfG
Niels

--
| 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 wrote:
> Hadanite Marasek schrieb:
>
>> Nun, ich will das Objekt ja dem Konstruktor des anderen übergeben. Ich
>> habe auch nichts dagegen, Objekte zu konfigurieren, nur teile ich gerne
>> Zuständigkeiten auf.
>
> Was für ein Fall ist das, wo du dem Konstruktor optional ein Objekt
> übergeben musst? Das hört sich für mich erstmal nach suboptimaler
> Architektur an...

Genau diesen Fall habe ich relativ häufig (wenn auch nicht die Probleme
des OP): Meine Datenbankanbindung ist ein Objekt, das quasi ein
erweitertes Singleton ist - über getInstance() bekommt man die Instanz
die die Standardverbindung verwaltet (oft brauche ich nur das) und über
eine andere Methode kann man ein weiteres Objekt erstellen, dass eine
andere Datenquelle benutzt.

Daher habe ich dann oft folgendes Kostrukt:

function __construct (IDb $dbInstance = null) {
if ($dbInstance === null) {
$this->dbInstance = DbWhatever::getInstance();
} else {
$this->dbInstance = $dbInstance;
}
}

Was ist daran suboptimal?
Ich frage, weil es mich wirklich interessiert ob ich da noch optimieren
kann.

regards,
Jens

Jens Himmelrath schrieb:
> Was ist daran suboptimal?
> Ich frage, weil es mich wirklich interessiert ob ich da noch optimieren
> kann.

eine Connection ist bei mir ein normales Objekt, welches in einem
ConnectionManager hinterlegt wird unter einem eindeutigen Bezeichner.
Dieser ist als Singleton implementiert, sodass ich von überall mir die
Connections holen kann. Gebe ich keinen Namen an, bekomme ich die
Standardconnection, welche unter dem Bezeichner "default" gespeichert wurde.

Dies war für mich die optimale Lösung, da ich mehrere Connections
ermöglichen will zu verschiedenen Datenbanken. Braucht man _immer_ nur
eine Connection sollte man eher die Connection selbst zum Singleton machen.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Niels Braczek schrieb:
> Hadanite Marasek schrieb:
>
>> Nun, ich will das Objekt ja dem Konstruktor des anderen übergeben. Ich
>> habe auch nichts dagegen, Objekte zu konfigurieren, nur teile ich gerne
>> Zuständigkeiten auf.
>
> Was für ein Fall ist das, wo du dem Konstruktor optional ein Objekt
> übergeben musst? Das hört sich für mich erstmal nach suboptimaler
> Architektur an...

Wo habe ich das geschrieben? Optionale Parameter möchte ich ja gerade
vermeiden.

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/
Ansonsten:
http://www.php-faq.de/q/q-newsgroup-wie-helfen.html

Christoph Herrmann wrote:
> Jens Himmelrath schrieb:
>> Was ist daran suboptimal?
>> Ich frage, weil es mich wirklich interessiert ob ich da noch
>> optimieren kann.
>
> eine Connection ist bei mir ein normales Objekt, welches in einem
> ConnectionManager hinterlegt wird unter einem eindeutigen Bezeichner.
> Dieser ist als Singleton implementiert, sodass ich von überall mir die
> Connections holen kann. Gebe ich keinen Namen an, bekomme ich die
> Standardconnection, welche unter dem Bezeichner "default" gespeichert
> wurde.

Ich hab quasi den "ConnectionManager" in getInstance() über einen
Parameter eingebaut. Wenn ich etwas anderes als die Standardverbindung
brauche gebe ich einen Parameter an.
Intern werden die Verbindungen genau wie bei dir in einem statischen
Array gespeichert.

regards,
Jens

Jens Himmelrath schrieb:
> Niels Braczek wrote:

>> Was für ein Fall ist das, wo du dem Konstruktor optional ein Objekt
>> übergeben musst? Das hört sich für mich erstmal nach suboptimale=
r
>> Architektur an...
>
> function __construct (IDb $dbInstance =3D null) {
> if ($dbInstance =3D=3D=3D null) {
> $this->dbInstance =3D DbWhatever::getInstance();
> } else {
> $this->dbInstance =3D $dbInstance;
> }
> }
>
> Was ist daran suboptimal?
> Ich frage, weil es mich wirklich interessiert ob ich da noch optimieren=

> kann.

prinzipiell zwei Möglichkeiten:

class A {
function __construct ( IDb $dbInstance ) {
$this->dbInstance =3D $dbInstance;
}
}

Aufruf mit
new A( $dbInstance );
oder
new A( DbWhatever::getInstance() );

Andere Möglichkeit:

class A {
function __construct ( $db_type=3D'default' ) {
$this->dbInstance =3D DbWhatever::getInstance( $dbType );
}
}

Aufruf mit
new A( 'whatever' );
oder
new A();

MfG
Niels

--
| 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 wrote:
> Jens Himmelrath schrieb:
>> Niels Braczek wrote:
>
>>> Was für ein Fall ist das, wo du dem Konstruktor optional ein Objekt
>>> übergeben musst? Das hört sich für mich erstmal nach suboptimaler
>>> Architektur an...
>> function __construct (IDb $dbInstance = null) {
>> if ($dbInstance === null) {
>> $this->dbInstance = DbWhatever::getInstance();
>> } else {
>> $this->dbInstance = $dbInstance;
>> }
>> }
>>
>> Was ist daran suboptimal?
>> Ich frage, weil es mich wirklich interessiert ob ich da noch optimieren
>> kann.
>
> prinzipiell zwei Möglichkeiten:
>
> class A {
> function __construct ( IDb $dbInstance ) {
> $this->dbInstance = $dbInstance;
> }
> }
>
> Aufruf mit
> new A( $dbInstance );
> oder
> new A( DbWhatever::getInstance() );
>
> Andere Möglichkeit:
>
> class A {
> function __construct ( $db_type='default' ) {
> $this->dbInstance = DbWhatever::getInstance( $dbType );
> }
> }
>
> Aufruf mit
> new A( 'whatever' );
> oder
> new A();

Meins ist also eine Mischung aus deinen Möglichkeiten:

new Something();
oder
new Something(Db::getInstance('whatever'));


Aber eine Begründung habe ich aus deinem posting nicht gelesen.

regards,
Jens

Jens Himmelrath schrieb:

> Aber eine Begründung habe ich aus deinem posting nicht gelesen.

Der entscheidende Punkt ist, dass entweder *immer* ein Objekt übergeben=

wird oder in der anderen Variante ein optionaler *skalarer* Parameter
(Konfigurationsschalter).

Die erstere Variante ist vorzuziehen, weil das Objekt dann weniger über=

seine "Umwelt" wissen muss. Du kannst irgendein Objekt übergeben,
solange es die korrekte Schnittstelle implementiert.

MfG
Niels

--
| 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 wrote:
> Jens Himmelrath schrieb:
>
>> Aber eine Begründung habe ich aus deinem posting nicht gelesen.
>
> Der entscheidende Punkt ist, dass entweder *immer* ein Objekt übergeben
> wird oder in der anderen Variante ein optionaler *skalarer* Parameter
> (Konfigurationsschalter).

Und wieso ist es besser wenn nur skalare Parameter optional sind?

> Die erstere Variante ist vorzuziehen, weil das Objekt dann weniger über
> seine "Umwelt" wissen muss. Du kannst irgendein Objekt übergeben,
> solange es die korrekte Schnittstelle implementiert.

Und als Ergebnis aus beidem ziehe ich dann den Schluss (besser gesagt,
sehe darin ein Argument für mein bisheriges Vorgehen) und mache einen
optionalen Objekt-Parameter (Typehint Interface), das im Falle eines
Falles per skalarem Parameter der getInstance-Methode erstellt werden kann.

Wenn du jetzt natürlich ein Argument gegen optionale Objekt-Parameter
hast - her damit.

regards,
Jens

Jens Himmelrath schrieb:
> Niels Braczek wrote:

>> Der entscheidende Punkt ist, dass entweder *immer* ein Objekt überge=
ben
>> wird oder in der anderen Variante ein optionaler *skalarer* Parameter
>> (Konfigurationsschalter).
>
> Und wieso ist es besser wenn nur skalare Parameter optional sind?
>
> Wenn du jetzt natürlich ein Argument gegen optionale Objekt-Parameter=

> hast - her damit.

Keines außer der Handhabung. Skalare kannst du beliebig vorbesetzen,
Objekte nicht. Innerhalb der Methode hast du immer einen
ordentlichen[tm] Wert. Wenn du statt eines Objektes null (nichts)
übergibst, muss dein Objekt zusätzliches "Wissen" über den Rest der=

Applikation haben, nämlich wer die zuständige Instanz ist, wenn sich
keiner "freiwillig meldet".

Wählst du Variante, *immer* ein Objekt zu übergeben, muss dein Objekt=

nur die Schnittstelle kennen. Egal ob das übergebene Objekt ein
Singleton oder ein Mock-Objekt (wichtig für Unit-Tests) ist oder nicht.=


Für die Variante mit dem Skalar muss dein Objekt nur die Factory kennen=
,
die ein Objekt mit der definierten Schnittstelle liefert. Auch hier ist
über das übergebene Objekt sonst nichts bekannt.

In jedem der beiden Fälle gibt es *eine* Stelle, an der das benötigte=

Objekt erzeugt wird. Im ersten Falle außerhalb, im zweiten innerhalb de=
s
Konstruktors (genauer: in der Factory) deines neuen Objektes.

Deine Variante hingegen hat doppelt so viele (nämlich zwei) Orte, an
denen das Parameter-Objekt erzeugt werden kann: außerhalb *und*
innerhalb. Somit hast du doppelt so viele Fehlerquellen.

MfG
Niels

--
| 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:
> Jens Himmelrath schrieb:
>> Niels Braczek wrote:
>
>>> Der entscheidende Punkt ist, dass entweder *immer* ein Objekt übergeben
>>> wird oder in der anderen Variante ein optionaler *skalarer* Parameter
>>> (Konfigurationsschalter).
>> Und wieso ist es besser wenn nur skalare Parameter optional sind?
>>
>> Wenn du jetzt natürlich ein Argument gegen optionale Objekt-Parameter
>> hast - her damit.
>
> Keines außer der Handhabung. Skalare kannst du beliebig vorbesetzen,
> Objekte nicht. Innerhalb der Methode hast du immer einen
> ordentlichen[tm] Wert. Wenn du statt eines Objektes null (nichts)
> übergibst, muss dein Objekt zusätzliches "Wissen" über den Rest der
> Applikation haben, nämlich wer die zuständige Instanz ist, wenn sich
> keiner "freiwillig meldet".
>
> Wählst du Variante, *immer* ein Objekt zu übergeben, muss dein Objekt
> nur die Schnittstelle kennen. Egal ob das übergebene Objekt ein
> Singleton oder ein Mock-Objekt (wichtig für Unit-Tests) ist oder nicht.

Ich muss gestehen, da ich auf der Arbeit bisher noch nicht mit Unit
testing in Kontakt gekommen bin, kann ich hier nicht mitreden. Es steht
jedoch seit längerem auf meine ToDo-Liste. Hast du eventuell sogar ein
paar nette Links zu dem Thema gerade im Bezug auf PHP?

> Für die Variante mit dem Skalar muss dein Objekt nur die Factory kennen,
> die ein Objekt mit der definierten Schnittstelle liefert. Auch hier ist
> über das übergebene Objekt sonst nichts bekannt.

Ich glaube jetzt habe ich deine Kritik erfasst: In meinem Konstruktor
steht ein direkter Bezug auf DbWhatever::getInstance() was natürlich in
sofern nicht flexibel ist, falls man einmal etwas anderes als DbWhatever
nutzen will. Got your point.

Das ist genau der Grund, wieso ich das usenet mag - ich wäre
wahrscheinlich erst dann von alleine auf das Problem gestoßen, wenn ich
eine neue Version meine Db-abstraction geschrieben hätte und die einen
neuen Namen bekommen hätte.
Obwohl das natürlich auch nicht unbedingt passieren muss, denn das eine
mal, wo ich die Abstraktion komplett neu geschrieben habe, bin ich
dennoch 100% kompatibel geblieben und habe den Namen natürlich beibehalten.

regards,
Jens

Jens Himmelrath schrieb:

> Ich muss gestehen, da ich auf der Arbeit bisher noch nicht mit Unit
> testing in Kontakt gekommen bin, kann ich hier nicht mitreden. Es steht=

> jedoch seit längerem auf meine ToDo-Liste. Hast du eventuell sogar ei=
n
> paar nette Links zu dem Thema gerade im Bezug auf PHP?

Es gibt eigentlich nur PHP Unit: http://www.phpunit.de/, war früher mal=

ein PEAR-Paket (http://pear.php.net/package/PHPUnit2/).

> Ich glaube jetzt habe ich deine Kritik erfasst: In meinem Konstruktor
> steht ein direkter Bezug auf DbWhatever::getInstance() was natürlich =
in
> sofern nicht flexibel ist, falls man einmal etwas anderes als DbWhateve=
r
> nutzen will. Got your point.

Richtig. Das ist ein wichtiger Aspekt. Und eben nicht zu vergessen, dass
du mit deinem Ansatz *zwei* mögliche Fehlerquellen prüfen müsstest.=


> Das ist genau der Grund, wieso ich das usenet mag - ich wäre
> wahrscheinlich erst dann von alleine auf das Problem gestoßen, wenn i=
ch
> eine neue Version meine Db-abstraction geschrieben hätte und die eine=
n
> neuen Namen bekommen hätte.
> Obwohl das natürlich auch nicht unbedingt passieren muss, denn das ei=
ne
> mal, wo ich die Abstraktion komplett neu geschrieben habe, bin ich
> dennoch 100% kompatibel geblieben und habe den Namen natürlich beibeh=
alten.

Irgendwann kommt immer der Fall, dass etwas ganz anders erweitert werden
muss, als man sich ursprünglich überhaupt vorstellen konnte. Das
passiert um so eher, je schwieriger die Umsetzung ist (Murphy's Law).

MfG
Niels

--
| 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:
> Jens Himmelrath schrieb:
>
>> Ich muss gestehen, da ich auf der Arbeit bisher noch nicht mit Unit
>> testing in Kontakt gekommen bin, kann ich hier nicht mitreden. Es steht
>> jedoch seit längerem auf meine ToDo-Liste. Hast du eventuell sogar ein
>> paar nette Links zu dem Thema gerade im Bezug auf PHP?
>
> Es gibt eigentlich nur PHP Unit: http://www.phpunit.de/, war früher mal
> ein PEAR-Paket (http://pear.php.net/package/PHPUnit2/).

Werde ich mir mal ansehen, danke.

>> Ich glaube jetzt habe ich deine Kritik erfasst: In meinem Konstruktor
>> steht ein direkter Bezug auf DbWhatever::getInstance() was natürlich in
>> sofern nicht flexibel ist, falls man einmal etwas anderes als DbWhatever
>> nutzen will. Got your point.
>
> Richtig. Das ist ein wichtiger Aspekt. Und eben nicht zu vergessen, dass
> du mit deinem Ansatz *zwei* mögliche Fehlerquellen prüfen müsstest.

Obwohl ich dieses Problem nicht für sehr groß halte, da ja im Kontruktor
jeweils die Standardversion abgerufen wird, also getInstance ohne
Parameter - das ist relativ einfach zu debuggen, wäre ja in der Factory
nicht viel anders.
Oder was genau meinst du für Fehler?

regards,
Jens

Jens Himmelrath schrieb:
> Niels Braczek schrieb:

>> Richtig. Das ist ein wichtiger Aspekt. Und eben nicht zu vergessen, da=
ss
>> du mit deinem Ansatz *zwei* mögliche Fehlerquellen prüfen müsste=
st.
>
> Obwohl ich dieses Problem nicht für sehr groß halte, da ja im Kontr=
uktor
> jeweils die Standardversion abgerufen wird, also getInstance ohne
> Parameter - das ist relativ einfach zu debuggen, wäre ja in der Facto=
ry

Im vorliegenden Fall ist das vielleicht noch überschaubar. Wir reden ja=

aber auch (ein wenig) über das Prinzip an sich. Grundsätzlich soll di=
e
Anzahl der Stellen, an denen ein bestimmter Vorgang durchgeführt wird,
minimiert werden. Damit reduziert sich eventueller Anpassungsbedarf.
Schon alleine unter diesem Gesichtspunkt ist es sauberer[tm], die
Erzeugung des Parameter-Objektes nur an einer Stelle vorzunehmen. Welche
die richtige ist, hängt davon ab, wer was über seine Umwelt weiß bz=
w.
wissen muss. Hier gilt: je weniger, desto besser.

MfG
Niels

--
| 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 =
|
------------------------------------------------------------ ------