Einem Object Werte oder Referenz übergeben?

[phpMorpheus2]

Hallo Leute.

Wenn eine Klasse z.B. eine ID braucht o.ä., wird diese als Parameter mitgeliefert.

Nun die Frage:
Sollte man immer nur den explizit benötigten Wert übergene,
oder eine Referenz des Objectes, welches den benötigten Wert enthält?

Beispiel:
Für das Lesen einer PN benötigt die PN Klasse die ID des angemeldeten Nutzers.
Instanziere ich nun ein user object und gebe das der pn klasse als referenz, sodass dann das erstellte pn object sich die benötigten Daten aus der Referenz zieht oder einfach nur den expliziten Wert?

Weil:
Wenn ich ein Object übergene und es mal ändern sollte, aus welchem Grund auch immer, dann müssen alle Klassen welche referenzen der user klasse nutzen auch umgeschrieben werden...

$user = new user();
$pn =  new pn($user);
// ... 

oder

$user = new user();
$wert = $user->id;

$pn =  new pn($wert); 

[onemorenerd]

Übergib das ganze User-Objekt. Die Klasse pn muss nämlich nicht zwangsläufig geändert werden, wenn sich die Klasse User ändert. Für sowas gibt es Interfaces.
Solange User das Interface implementiert, dass PN erwartet, ist alles okay. Damit hast du das Problem verlagert: User kann sich ändern, nur das Interface muss gleich bleiben. Das ist der Sinn von Interfaces, sollte also kein Problem sein.

interface Identifiable {
    public function getId();
}

class User implements Identifiable {
    public function getId() {
        return $this->id;
    }
}

class PN {
    public function __construct(User $user) {
        $uid = $user->getId();
    }
} 

Im Ctor von PN könnte man als Type Hint auch nur Identifiable verwenden. Aber semantisch gesehen wäre das imho zu lasch.
Ich würde stattdessen eher eine abstrakte Klasse einführen, die Identifiable implementiert, eine Property id hat und den Getter dafür. Auf diese abstrakte Klasse würde ich den Type Hint setzen, wenn man mich dazu überredet.

[ModestLife]

Was spricht gegen das Interface als Type Hint? Abgesehen von deinem Vorschlag mit der abstrakten Klasse, macht das Beispiel ansonsten keinen Sinn. :-)

interface Identifiable {
    public function getId();
}

// Interface brauchen wir aus irgendeinem Grund nicht mehr ...
class User {
    public $id;
}

class PN {
    public function __construct(User $user) {
        $uid = $user->getId(); // Fail, Methode gibt's nicht mehr
    }
} 

[onemorenerd]

Was spricht gegen das Interface als Type Hint?

Das Interface ist semantisch schwächer als eine konkrete Klasse. PN braucht nicht die Id von irgendeinem Objekt sondern von einem User.
Angenommen wir machen

class PN {
    public function __construct(Identifiable $user) { ... }
}

class Product implements Identifiable { ... }

$pn = new PN(new Product($id)); 

Das funktioniert, und genau das soll es nicht. Denn später wird sowas kommen wie $pn->save().
Dabei landet die PN z.B. in der DB. Dummerweise mit einer Produkt-Id in der uid-Spalte. Wenn es zufällig einen User mit diese Id gibt ....

[phpMorpheus2]

Habe ich eine Möglichkeit, beim instanzieren eines Objects einen Wert zurückzugeben?

Ich setze versch. Werte in der __construct, aber diese kann keinen Rückgabewert abgeben.
Gibt es da eine Möglichkeit?

Danke

[unset]

Noe, ist aber auch nicht nötig. Im Erfolgsfall hast du das Objekt, im Fehlerfall eine Exception.

[phpMorpheus2]

Noe, ist aber auch nicht nötig. Im Erfolgsfall hast du das Objekt, im Fehlerfall eine Exception.

Auch war.

[phpMorpheus2]

Ich sehe immer wieder, dass viele Leute Ihre Klassen in ganz viele Methoden aufteilen und diese nacheinander abklappern.

Jedoch finde ich es manchmam übertrieben, für selbst nur eine abfrage eine Methode zu basteln welche nur 1. programmzeile enthält.

Ist das so "gängig" oder schon eine Art der übertreibung?

Wenn ich finde, eine Methode kann so gestaltet bleiben, auch wenn Sie etwas größer ist, jedoch keine Funktion in der Methode jemals von etwas anderem gebraucht wird, so bleibt die große Methode so, wie sie ist.

Oder doch lieber alles schön aufteilen?

z.B. jede SQL Abfrage und das Ergebnis return'n usw.

Danke

[onemorenerd]

Erstmal alles in der Funktion lassen. Aber sobald sich der selbe oder ähnliche Code an anderer Stelle wiederholt, anfangen zu refaktorieren.

Les- und Wartbarkeit sollte allerdings auch eine Rolle spielen.

[PHP-Desaster]

Sobald eine meiner Methoden länger wie 20 Zeilen wird, versuche ich diese aufzuteilen. Generell solltest du in einem kurzen Satz erklären können, was die Methoden macht. Benötigst du ein und oder mehrere Sätze, wird es Zeit zum Aufteilen. Der Vorteil der Aufteilung ist die Übersicht und erbende Klassen können einzelne Teile der Funktion gezielt überschreiben. Sehr gerne nutze ich eine einzelne öffentliche Methode, welche den eigentlichen Vorgang an mehrere Untermethoden delegiert. Über Chaining ist das super zu lesen:

class Blubb {
    public function doIt() {
        return $this
            ->loadData()
            ->transformBlubb()
            ->somethingElse()
            ->createResponse();
    }
} 

Im Fehlerfall wird einfach eine Exception geworfen. Außerdem ist es für diese Methode völlig transparent, ob eine Untermethode auf weitere Objekte zugreift (die createResponse-Methode zum Beispiel auf eine ResponseRenderer-Klasse oder loadData auf die Datenbank?), der Ablauf ist aber ganz klar definiert. Und im Fehlerfall? Einfach die Exception fliegen lassen.

[phpMorpheus2]

Erstmal alles in der Funktion lassen. Aber sobald sich der selbe oder ähnliche Code an anderer Stelle wiederholt, anfangen zu refaktorieren.

Les- und Wartbarkeit sollte allerdings auch eine Rolle spielen.

Hm.. Gut.

[phpMorpheus2]

Ich habe oft das Problem, nicht zu wissen, wo ich eine Methode einordnen soll.
z.B. besitzt die Klasse "user" mehrere Methoden, welche den user betreffen wie z.B. ein bestimmtes Detail über den User ausgeben wie das Alter o.ä. und dann gibt es Situationen, da möchte ich z.B. den Pfad und den Dateinamen des Profilbildes des Users haben.

Erstelle ich nun eine neue user Methode z.B. get_user_picturepath oder verbau ich diese lieber in der class.picture.php, in welcher auch uploadmethoden des userbildes vorhanden sind?

Hach, das ist manchmal garnicht so leicht finde ich

[PHP-Desaster]

Dein Problem liegt einfach darin, dass du die Methoden in bereits vorhandene Klassen einsortieren willst. Wie du schon sagst, die get_user_picturepath-Methode passt nicht recht in die user-Klasse, aber auch irgendwie nicht in die picture-Klasse, beide hätten aber was mit dieser Methode zu tun. Lösung: Eine neue Klasse erstellen, welche dann über eine user- und picture-Instanz den Vorgang ausführen kann. Und alles was du momentan schon an Userbild-Methoden in der picture-Klasse hast, refaktorisierst du in diese Klasse.

[phpMorpheus2]

Ja aber dann habe ich später ja zich php-Dateien!?

[unset]

Und wo ist das Problem? Ein durchschnittliches Projekt von mir hat (jenseits der eingesetzten Frameworks) gerne mal mehrere Hundert eigene Klassen – in jeweils eigenen Dateien. Alles eine Frage der Organisation.