nicht angemeldet
Moin!
-Ich hab da noch immer Probleme mit "protected", "public" usw. Passt das jetzt so wie ich es gemacht habe?
Steht for allen Variablen und Funktionen entweder "protected" oder "public"? Nein. Schreibs hin.
Du hast eine ganz blöde Idee, indem du die Login-Klasse alles von der Mysql-Klasse ERBEN lässt. Das Login ist keine Datenbankklasse, muss also auch nichts erben. Das Login VERWENDET Datenbankzugriffe, benötigt also seinerseits im Konstruktor ein Datenbankobjekt übergeben, welches dann in einer protected-Variable gespeichert wird.
Dein Suchwort für weitere Infos zu diesem Thema lautet "Dependency Injection". Meine empfohlene Vorgehensweise, wenn man für sowas keine eigenen Frameworks verwenden will: Alle normalen Klassen kümmern sich um das Funktionieren hinsichtlich ihrer Aufgabe, und das Zusammenbauen von Objekten geschieht in Factory-Klassen, die wiederum ausschließlich nur Objekte korrekt zusammensetzen. In diesem Fall also eine Factory, die dir ein funktionierendes Login-Objekt zurückgibt, indem dem Konstruktor vom Login ein existierendes Mysql-Objekt übergeben wird - beide Objekte erstellt die Factory:
class Factory {
static public function getLoginInstance() {
$mysql = new Mysql($config);
return new Login($mysql);
}
}
// Verwendung:
$login = Factors::getLoginInstance();
Zu klärende Details: Wo kommt die Konfiguration her? Schlauerweise auch aus einer entsprechenden Klasse, die Alternative wäre alles, was global verfügbar ist, also z.B. Konstanten, globale Variablen. Singletons. Oder (das ist für derartige Dinge, wenn sie objektorientiert umgesetzt werden, der Favorit) eine Registry, also ein Objekt, welches Objekte entgegennimmt, deren Einmaligkeit in einem laufenden Skript garantiert, und sie an jeder beliebigen Stelle wieder zur Verfügung stellt.
Suchwort an dieser Stelle wäre "Registry pattern".
Kritiker würden natürlich anmerken, dass eine Registry nix anderes macht, sich für multiple Objekte als Singleton zu verhalten, aber der Unterschied zu einem echten Singleton ist, dass eine Registry sich nur um das Annehmen, Unique-Halten und Ausliefern von Objekten kümmert. Das ist ein sehr kleiner Aufgabenbereich, den man auch mal ohne automatisierten Test realisieren kann. Ein Singleton-Objekt hingegen tut ja in der Regel ganz viele nützliche Sachen - die Singleton-Eigenschaft aber untrennbar zu verbinden mit diesen wichtigen Dingen, die man unbedingt testen sollte, ist aber gerade hinderlich.
Einen Konstruktor, wie in der Mysql-Klasse geschehen, protected zu machen ist in der Regel eine ganz schlechte Idee, solange man kein Singleton bauen will (udn das will man in der Regel nicht).
PHP bietet für Funktionsparameter, die Objekte eines bestimmten Typs sein sollen, Typehinting an. Unbedingt benutzen! Kostet zwar winzig Performance, aber das ist viel besser, als wenn eine Klasse das falsche Objekt bekommt und dann in der Funktion komische Fehler wirft.
-Zu
~~~php
ini_set('session.use_only_cookies', '1');
ini_set('session.use_trans_sid', '0');
>
> würd ich mich auch noch über einen Lösungsvorschlag freuen.
Das ist PHP-Konfiguration, gehört wenn, dann zentral in eine überall eingebundene Konfigurationsdatei, oder besser noch in die Konfiguration deines PHP. Also php.ini, ggf. auch nur lokale php.ini oder .htaccess, je nach Art der Einbindung des PHP in deinen Server.
> -Wegen dem Entfernen der Stripslashes: ich hab jetzt das ganze in der "login.php" gemacht nur frag ich mich ob es nicht doch besser wäre das mit einer Funktion in der "login.class.php" zu machen...
> -die superglobalen Variablen: Ich greif doch eh mit $config darauf zu ?
$\_SESSION, $\_COOKIE, $\_POST, $\_GET sind superglobale Variablen. Kommen die in deinen Klassen vor, oder nicht?
> -das mit dem Update beim Login werd ich noch machen
>
> -Ich speicher jetzt noch zusätzlich fehlgeschlagene Anmeldungen in der DB, hab das aber noch nicht getestet, sollte aber hin hauen.
- Sven Rautenberg