[gelöst] Anfängerfragen OOP

[Lalelu]

Hallo, ich bin gerade dabei mich in OOP einzuarbeiten, wobei sich einige Fragen bei mir aufgetan haben.

Frage 1:
Wie ich gelesen habe, werden zu Beginn in einer Klasse alle Eigenschaften eines Objektes angegeben. In einem Konstruktor werden diesen Eigenschaften dann Werte zugewiesen. Aber irgendwie seh ich den Sinn dahinter nicht ganz. Hab mal versucht, eine Klasse für eine User-Registrierung zu erstellen, was soweit auch funktioniert. Wenn ich aber die ganzen Eigenschaften (private $vorname, private $nachname, ...) am Anfang rauslösch, funktioniert das alles trotzdem noch so wie es soll. Wozu ist dann die Auflistung gut, was bringt mir das? Nur um die Eigenschaften als private/public/protected zu deklarieren? Würden die dann wenn ich auf die Auflistung am Anfang verzichten würde quasi alle automatisch auf public stehen? Oder hat die Auflistung noch irgendwie eine andere Bewandnis? Also hier mal der Anfangsteil zum besseren Verständnis:

class User
{
  private $vorname;
  private $nachname;
  private $email;
  private $username;
  private $passwort;

  public function __construct($userdaten){
  $this->vorname = $userdaten[0];
  $this->nachname = $userdaten[1];
  $this->email = $userdaten[2];
  $this->username = $userdaten[3];
  $this->passwort = $userdaten[4];
  }

  ...
  ...
} 

Frage 2:
Angenommen ich möchte in die Klasse nun auch Methoden zum Login/Logout einfügen. Da brauch ich ja als Eigenschaften nur Username und Passwort. Im Konstruktor könnt ich ja dann durch eine if-Bedingung rausfinden, ob sich ein User registrieren oder einloggen will und demnach entscheiden, ob nur dem Usernamen und Passwort Werte zugewiesen werden oder auch Vorname, Nachname und Email. Was mach ich dann aber mit den Eigenschaften am Anfang der Klasse (die Dinger mit dem private davor)? Kann ich die einfach so alle stehen lassen obwohl einige im Falle eines Logins nicht gefüllt bzw. genutzt werden oder wie ist das?

Frage 3:
Muss man jedes Mal, wenn man einen Konstruktor erstellt hat auch einen Destruktor erstellen oder ist das optional? Hinter den Sinn so eines Destruktors bin ich auch noch nicht so ganz gestiegen...

Frage 4:
Ich hab mal gehört, in Methoden soll man kein echo verwenden. Weiß einer den Grund dafür?


Fragen über Fragen... Hoffe ihr könnt mir helfen!

[combie]

1. ja
2. unsinn
3. jain
4. ja

[onemorenerd]

Frage 1:
Wenn ich aber die ganzen Eigenschaften (private $vorname, private $nachname, ...) am Anfang rauslösch, funktioniert das alles trotzdem noch so wie es soll. Wozu ist dann die Auflistung gut, was bringt mir das? Nur um die Eigenschaften als private/public/protected zu deklarieren? Würden die dann wenn ich auf die Auflistung am Anfang verzichten würde quasi alle automatisch auf public stehen?

Ja, ohne explizites Auflisten kannst du die Sichtbarkeit der Properties nicht angeben und dann sind sie alle public. Außerdem hätte man keine Code Completion der Properties und nicht zuletzt ist es einfach eine Frage der Wartbarkeit.

Frage 2:
Angenommen ich möchte in die Klasse nun auch Methoden zum Login/Logout einfügen. Da brauch ich ja als Eigenschaften nur Username und Passwort. Im Konstruktor könnt ich ja dann durch eine if-Bedingung rausfinden, ob sich ein User registrieren oder einloggen will ...

Das mag in deinem Fall grad so sein, aber generell kann man nicht davon ausgehen, dass man im Konstruktor schon irgendwas weiß. Man initialisiert das Objekt erstmal blanko, d.h. solche Properties wie Username und Passwort werden mit leeren Strings oder NULL belegt.
Sollte dem Konstruktor eine User-Id übergeben werden, kannst du die minimal benötigten Daten laden oder mehr als diese oder gleich alle. Was eben am sinnvollsten ist.

Frage 3:
Muss man jedes Mal, wenn man einen Konstruktor erstellt hat auch einen Destruktor erstellen oder ist das optional? Hinter den Sinn so eines Destruktors bin ich auch noch nicht so ganz gestiegen...

Der Sinn eines Destruktors ist, beim Abräumen des Objekts aufzuräumen. Es wäre zum Beispiel denkbar, dass so ein User-Objekt während der Laufzeit verändert wurde. Der User hat sein Passwort geändert oder so. Das Objekt mehr sich intern, dass diese Änderung noch nicht persistent ist, also zum Beispiel noch nicht in der Datenbank gespeichert wurde. Wird jetzt das Objekt vom Speicher entfernt, wird kurz zuvor der Destruktor aufgerufen und schreibt die Änderungen in die DB.*
Wenn im Destruktor gar nichts zu tun wäre, muss er auch nicht implementiert werden. Das dass Objekt aus dem Speicher verschwindet, darum kümmert sich PHP schon selbst, spätestens beim Beenden des Skripts.

Frage 4:
Ich hab mal gehört, in Methoden soll man kein echo verwenden. Weiß einer den Grund dafür?

Wenn Methoden direkt Ausgaben erzeugen, sprechen sie quasi mit dem Browser. Aber das sollen sie nicht, sie sollen mit ihrem Aufrufer sprechen. Das heißt, sie sollen die zu erzeugende Ausgabe als String zurückgeben. Nur so läßt sich eine saubere Trennung zwischen Eingabe, Verarbeitung und Ausgabe erreichen. Wenn in einer objektorientierten Applikation jedes Objekt nach Belieben Ausgaben erzeugt, ist das meist ein deutliches Zeichen dafür, dass lediglich zusammengehörige Funktionen mit einem class{} umschlossen wurden. Ein echtes Objekt bildet aber eine Entität mit in sich konsistentem Verhalten und deutlich abgrenzbaren Zweck.

Üben, üben, üben ... und immer wieder andere draufschauen lassen.


*) Das ist nur ein Beispiel. Da Destruktoren u.U. erst beim Beenden des Skripts laufen, besteht die DB-Verbindung vielleicht schon gar nicht mehr.

[fireweasel]

...
4. ja

Ist das jetzt so eine typische Hacker-Antwort?
"Ja", es gibt mindestens einen, der den Grund dafür weiß.

Oder ging es dir darum, dass Memberfunktionen besser nicht in die Ausgabe schreiben sollten? Dann hättest du aber dem OP zumindest auch darauf hinweisen können, dass es neben echo() noch eine ganze Menge andere Ausgabefunktionen wie print(), printf() oder vprintf() gibt. Sonst sieht das so aus, als ob nur die Verwendung echo() "böse" wäre.

Ich würde übrigens die vierte Frage mit "kommt darauf an" beantworten. Irgendwo muss man die gesammelten Bytes schließlich mal ausgeben.

[combie]

Weiß einer den Grund dafür?
Ja!

Ich kenne den Grund warum ich das nicht (oder nur ganz ganz selten) tue! Onemorenerd hat ihn sehr gut beschrieben. Dem gibt es nichts mehr hinzuzufügen.

[unset]

Ich hab aus Spaß grade mal geschaut. In einer von mir entwickelten Abart des Zend Frameworks kommen 9 echo's vor. Alle auskommentiert … im ZF finden sich allerdings per default einige.

Ich gehe sogar so weit, dass man komplett ohne "echo" arbeiten kann, wenn man will. Aber Zeitdruck, Faulheit und Frustration sind eben nicht immer im Keller

[combie]

Echos sind an sich nicht böse...
Aber in Methoden haben sie selten was zu suchen.
Ausnahme im V des MVC

Selbst in Funktionen ist ein echo meist unnötig einschränkend.

function mul_a($a,$b) 
{
  echo $a*$b; // böse
}

function mul_b($a,$b) 
{
  return $a*$b; // gut
}

mul_a(1,2);// böse
echo '<br>';
echo mul_b(1,2);// gut 

mul_a ist böse weil sich die Rückgabe nicht weiterverarbeiten lässt.

[h3ll]

Außerdem werden Unit Tests ziemlich aufwändig, wenn nicht sogar unmöglich, wenn alles mit echo ausgegeben wird.