nicht angemeldet
Moin!
Das mit dem Menu war aber glaube ich keine Gute Idee. Sieht zwar leicht aus, aber die Objektiteration macht mich jetzt schon ganz Bibber und Bange.
Es war die beste Idee, die sich angeboten hat. :)
Können wir vielleicht auf etwas leichteres umsteigen? Eine leichte Übung wäre Angepasste Inhalte für mobile Endgeräte (hoffe ich zumindest :)).
OOP wird nicht leichter, wenn man was anderes macht, denn es geht immer und jederzeit um die gleichen Prinzipien: Das Trennen von Zuständigkeiten in eigenständige Objekte, die ihrerseits für andere Zuständigkeiten weitere Objekte benutzen, dies nach außen aber nicht zeigen.
Insofern sorgt OOP, wenn sie gut gemacht ist, für eine Reduktion der gefühlten Komplexität an jeder Stelle des Codes. Die Gesamtkomplexität ist zwar weiterhin hoch, allerdings ist an keiner Stelle eine besorgniserregende Konzentration von Komplexität zu sehen, denn die wäre schädlich.
Es gibt für die Erstellung von OOP-Lösungen ein schönes Wort: "S.O.L.I.D."
S - Single Responsibility: Eine Klasse sollte genau einen Zweck haben, nicht mehr als einen. Wenn in der Antwort auf die Frage "Was tut die Klasse?" ein "und" vorkommt, dann tut die Klasse vermutlich mehr als eine Sache - schlecht!
O - Open-closed Prinziple: Eine Klasse sollte offen für Erweiterungen, aber geschlossen gegenüber Veränderungen sein. Das geht vor allem in die Problematik, ob man eine Klasse nochmal extenden sollte, oder sie lieber unverändert benutzt, und die Variation außenherum programmiert.
L - Liskov Substitution Prinziple: Das ist wohl die komplexeste Forderung der fünf. Eine Klasse A kann andere Klassen (z.B. B) zum Arbeiten benutzen sollen. Nach dem Liskov-Ersetzungs-Prinzip soll man sowohl die Klasse A erweitern können zu A', oder auch die Klasse B zu B', ohne dass dadurch irgendwelche Methoden der Grundklassen inkompatibel geändert werden.
I - Interface Segregation Principle: Spezielle kleinere Interfaces für eine konkrete Aufgabe sind besser, als ein großes, allgemeines Interface.
D - Dependency Inversion Principle: Dahinter verbirgt sich u.A. das, was als Dependency Injection bekannt ist. Wenn eine Klasse eine weitere Klasse für Unteraufgaben benötigt, soll es diese Klasse nicht selbst instanziieren, sondern sich von außen hereinreichen lassen.
Ich habe damit mal rumgespielt (das mit dem Menu ist mir derzeit zu Hoch), und habe das Bsp. vom Dirk in eine Klasse gepackt.
Dirk hat nur eine Funktion in seinem Artikel gehabt. Den in ein OOP-Beispiel umzusetzen ist nicht sehr leicht. Oder schwer - dann aber nicht wirklich OOP. :)
Die Klasse soll ermitteln, ob der anfordernde Client ein Mobil-Gerät ist, oder nicht (das funktioniert bereits).
Wenn man da jetzt OOP einbringen will, würde ich folgende Aspekte mal hinterfragen:
1. Woher kommt die Liste der erkennbaren User-Agents, die "mobil" sind? Da die Liste nicht auf kosmisch konstanten Fakten basiert, gibt es keinen Grund, sie statisch im Code einzubauen, sondern man würde sie leichter veränderbar in einer Konfigurationsdatei halten. Daraus folgt: Deine Klasse benötigt ein Konfigurationsobjekt, mit dem die Liste der User-Agent-Werte ausgelesen werden kann, und diese Klasse kann wiederum Unterobjekte benutzen, um sich z.B. an INI-Dateien, XML-Dateien oder Datenbanken anzudocken - oder auch ganz normale PHP-Arrays in Include-Dateien auslesen.
2. Der zweite Punkt ist das Auswerten des aktuellen HTTP-Requests. Hier direkt auf die superglobalen Variablen zuzugreifen ist zwar möglich, aber nicht elegant oder OOP. Eigentlich sollte man hier lieber ein Request-Objekt haben, in dem die aktuellen Zustände des laufenden HTTP-Requests vom Browser gekapselt sind. Dieses Objekt wird in einer PHP-Applikation an einer zentralen Stelle mit den Inhalten der superglobalen Variablen gefüllt und von dort aus an die Stellen weitergetragen, die sich im Sinne der Applikation für den Request interessieren sollen.
3. Ich bin auch kritisch eingestellt gegenüber der Strategie, schon sehr viel im Konstruktor auszuführen. Da Objekte üblicherweise erst einmal erstellt werden, und eventuell nie benutzt werden, zumindest nicht in allen Aspekten, sollte man die Dinge, die nicht zwingend zur Lebensfähigkeit des Objekts gehören, möglichst erst dann ausführen, wenn es tatsächlich notwendig ist.
4. Am Ende noch ein wenig Codekritik zu den Namen der Methoden: Wir haben "isMobile" und "GetDevice" - einmal klein und einmal groß.
5. Und der Namen der public Property "_device" ist auch nicht so glücklich - mit Unterstrichen hat man zu Zeiten von PHP 4, als alle Properties public waren, die gekennzeichnet, die man als protected oder private ansehen wollte und deshalb nicht von außen benutzen sollte.
Darüberhinaus muss die Klasse auch mit Cookies und GET-Variablen arbeiten. Sollte ich diese Variablen von Aussen mittels Parametern der Klasse übergeben, oder soll ich hier innerhalb der Klasse direkt auf die Globalen Variablen zugreifen?
Meine Idee für die Klasse wäre so:
class CheckMobile
{
public $_device; // @return "Mobile" oder "Desktop"
// Sind die Useragents hier richtig aufgehoben?
private $_agents = array('up.browser','up.link','mmp','symbian','smartphone'
,'midp','wap','phone','Windows CE','Pocket','mobile'
,'-mobile','portable','SDA','PDA','handheld','iemobile'
,'palmos','minimo','avantgo','cHTML','blackberry'
,'opera mini','fennec','nokia','googlebot-mobile');public function __construct()
{
$this->_device = $this->GetDevice();
}private function isMobile() // Prüfen der Browserkennung
{
for ($i = 0; $i < count($this->_agents); $i++)
if (isset($_SERVER["HTTP_USER_AGENT"]) AND strpos(strtolower($_SERVER['HTTP_USER_AGENT']), $this->_agents[$i]) !== false)
return true;
return false;
}private function GetDevice()
{
if ($this->isMobile())
return 'Mobile';
else
return 'Desktop';
}}
// Aufruf
$_device = new CheckMobile();
echo $_device->_device;
- Sven Rautenberg