PHP: OOP, Design Patterns und UML - Comelio · PDF file18 1.1 Einfache Klassen 1. 1. Aufbau...

Einfache Klassen

17

1. Einfache Klassen 1

1. Einfache Klassen

Bücher zum Thema Objektorientierung wählen ganz unterschiedliche Wege, um die Techniken und Vorzüge dieser Programmiertechnik darzustellen. Während in Programmiersprachen wie Java oder .NET sowieso kein Weg an der Objektorien-tierung vorbeiführt und man höchstens schlechte objektorientierte Entwürfe er-stellen und sich daher an guter Planung und sinnvollem Einsatz dieser Technik vorbeimogeln kann, so ist dies im PHP-Bereich ganz anders.

Hier kann man durchaus in der Lage sein, auch große Anwendungen seitenweise mit prozeduralem Quelltext oder PHP-Inseln, die in XHTML eingebettet sind, zu er-stellen, welche dann bspw. sogar ohne ausgelagerte prozedurale Funktionen sein können. In diesem Fall ist es immer schwierig nachzuweisen, warum gerade eine solche Konstruktion nicht die gleichen Vorteile bringen soll wie ein objektorien-tierter Entwurf, denn die Anwendung erfüllt mit Sicherheit ihren Zweck und funk-tioniert – wenn vielleicht auch Änderungen am Quelltext nicht sehr einfach sind.

Da die Leser dieses Buchs vermutlich durchaus die Meinung hegen, der Einsatz der OOP würde sich in ihren Projekten bezahlt machen, soll hier weniger allgemei-ne Werbung für die Objektorientierung gemacht werden, sondern vielmehr an-hand von praktischen Beispielen gezeigt werden, wie nützlich diese Technik auch für PHP-Entwickler ist.

Dieses Kapitel beginnt daher unmittelbar damit, die Syntax zur Erstellung und Ver-wendung von Klassen vorzuführen, um so weniger eine theoretische Basisinfor-mation zu geben, sondern unmittelbar die neuen Techniken in PHP vorzuführen. Ausgehend von einer einfachen Klasse werden natürlich gleichzeitig auch die Be-griffe der Objektorientierung dargestellt, wobei aber immer ein großer Bezug zum PHP-Quelltext gegeben ist.

18

1. Einfache Klassen1

1. 1. Aufbau einer Klasse

Eine Klasse lässt sich als grundlegender Baustein einer OOP-Software bezeichnen. Objektorientierung bezieht sich zwar begrifflich mehr auf die Objekte und nicht auf die Klassen, die man zunächst erstellen muss, um überhaupt Objekte zu ins-tanziieren (erstellen) zu können, aber dies liegt vermutlich mehr daran, dass hier die Programmsituation zur Laufzeit bildlich im Vordergrund steht. In dieser Situati-on nämlich besteht zwar die Möglichkeit, Objekte auf Basis von Klassen zu bilden, aber zu einem gegebenen Systemzeitpunkt existieren in der Software ausschließ-lich Objekte. Diese bezeichnet man auch als Exemplare oder Instanzen ihrer Klas-se. Die letzten beiden Begriffe zeigen damit auch sehr schön, wie man sich den Unterschied zwischen einer Klasse und einem Objekte vorstellen muss.

Eine Klasse ist ein Bauplan/eine Vorlage für Objekte. Sie legt die Struktur (Eigenschaften) und das Verhal-ten (Methoden) fest.

1. 1. 1. Eigenschaften und Methoden

Eine Klasse bildet eine Sammlung von Eigenschaften und Methoden. In den Ei-genschaften können Werte mit Hilfe von primitiven Datentypen (Zeichenketten, Zahlen, Wahrheitswerte, Arrays) oder auch wieder in Objektform gespeichert werden. Die Klasse bildet dabei eine Gussform, auf deren Basis sich konkrete Ob-jekte bilden lassen. Am einfachsten lässt sich dies immer an den Eigenschaften vorstellen. Diese könnte man auch als Felder wie in einem Array betrachten, wel-ches in PHP mit ganz unterschiedlichen primitiven Datentypwerten aufgefüllt sein kann. Genauso wie die Array-Variable immer den gleichen Namen haben kann, aber unterschiedliche Werte mit ebenfalls unterschiedlichen Datentypen spei-chern könnte, so muss man sich vorstellen, dass ein Objekt nur die möglichen Felder festlegt und erlaubt einem Klienten, diese Felder zu setzen. Es ist dabei natürlich – übrigens genauso wie bei einem Array, das bspw. aus einer Daten-

19


bankzeile geladen wird – sehr sinnvoll, wenigstens an den gleichen Plätzen bzw. in den gleichen Eigenschaften auch vergleichbare Werte zu speichern. Hier hilft der Array-Vergleich auch wiederum weiter, wenn man sich ein assoziatives Array nimmt und es genauer betrachtet. Zwar könnte man an solchen Index-Werten wie Vorname oder Geburtstag den Nachnamen und das Alter speichern, weil PHP nur schwach typisiert ist und daher keine Überprüfung stattfindet, ob in Vorname tatsächlich eine Zeichenkette und keine Zahl oder in Geburtstag ein Datumswert und kein Wahrheitswert gespeichert ist, doch dies ist weder guter Programmierstil noch könnte man erwarten, dass die HTML-Ausgaben den gewünschten Eindruck vermitteln.

So wie die Index-Werte eines assoziativen Arrays mit ihren beschreibenden Na-men die Bedeutung (Semantik) des gespeicherten Wertes näher angeben, so hel-fen die Eigenschaften einer Klasse, die gespeicherten Daten in einer Klasse zu un-terscheiden. Hier gibt es zwar ebenfalls wie beim Array keine direkte Möglichkeit, die primitiven Datentypen wirklich festzulegen, aber es versteht sich vermutlich von selbst, dass wechselnde Datentypen auf wechselnde Arten von Werten und damit auf fehleranfällige Programme schließen lassen.

Eine Klasse enthält Mitglieder (Member), darunter u. a.:

● Eigenschaften/Attribute/Felder beschreiben den Zustand und bilden den Zustand eines Objekts, in-dem sie Werte (ähnlich Variablen) speichern.

● Methoden/Operationen ermöglichen es, Eigen-schaften und übergebene Parameter zu verarbei-ten oder sonstige Funktionalität anzubieten (ähn-lich wie Funktionen).

Während ein Array nur die Möglichkeit bietet, mehrere Werte zu speichern und diese mit individuellen Index-Werten auszustatten, so bietet eine Klasse darüber hinaus noch eine weitere Möglichkeit, die für die Objektorientierung ganz ent-scheidend ist. Die Klasse kann nämlich zusätzlich auch noch so genannte Metho-

20


den enthalten. Syntaktisch handelt es sich dabei ganz einfach um die schon aus der prozeduralen PHP-Programmierung bekannten Funktionen, die allerdings zwi-schen die geschweiften Klammern der Klasse verschoben wurden. Sie gehören nun zu dieser Klasse und bieten Verarbeitungsalgorithmen für die gespeicherten Daten oder für Daten, die wiederum von außen übergeben werden, an. Damit lässt sich – nach einer älteren Vorstellung der Objektorientierung – eine Klasse als eigener Datentyp denken, der sowohl mehrere einzelne Werte speichern kann und auch weiß, wie diese verarbeitet werden können.

Abbildung 1.1: Aufbau einer Klasse

Zunächst sollen diese gerade gezeigten Fähigkeiten an einem einfachen Beispiel illustriert werden. Die meisten Beispiele stammen aus dem Bereich eines Webs-hops oder einer beliebigen Unternehmensanwendung. Daher ist die erste Klasse eine Klasse für einen Kunden.

Sie enthält sicherlich nicht alle Eigenschaften, d.h. Werte, die für die Verarbeitung und vor allen Dingen Speicherung eines Kunden sinnvoll sind, aber die Quelltexte sollen nicht allzu umfangreich werden, sodass hier ein Kunde nur einen Vorna-

21


men, Nachnamen und eine Nummer speichern kann. Dies sind dann die oben an-gekündigten Eigenschaften. Syntaktisch erstellt man diese Eigenschaften fast wie Variablen. Sie haben ebenfalls einen Namen und ein Dollar-Zeichen. Lediglich das Schlüsselwort public steht noch vor ihnen. Es kann aus Gründen der Abwärts-kompatibilität zu PHP4 auch entfallen, was gleichzeitig bedeutet, dass diese Eigen-schaften ebenfalls public sind. Dies bedeutet für die Verwendung der Klasse bei der Objekterstellung, dass diese Werte von außen direkt gelesen und geschrieben werden können.

Sofern dies erstaunt, weil man normalerweise sicherlich sich zunächst keine Ei-genschaften denken kann, die gerade nicht von außen zu verwenden sind, dann sei schon hier auf Beispiele weiter unten verwiesen. Der Zugriffsschutz von Eigen-schaften und Methoden ist ein wichtiges Thema, und man kommt sehr schnell in die Bedrängnis, gerade keinen öffentlichen Zugriff auf Eigenschaften und Metho-den erstellen zu dürfen oder zu können.

Die Methoden haben – wie schon eben erwähnt – den gleichen Aufbau wie Funk-tionen aus dem prozeduralen PHP. Sofern man also hier schon sehr intensiv mit Funktionen arbeitet, ist manchmal die Umstellung auf objektorientierte Struktu-ren relativ einfach zu bewerkstelligen. Im Wesentlichen sollte man seine Skripte ohnehin so organisiert haben, dass zusammenhängende Funktionen in einer Datei stehen. Dann müsste es eigentlich möglich sein, diese Funktionen bereits in die Dateien ersetzenden Klassen zu sammeln. Es sind dann zwar noch allerhand Um-bauarbeiten notwendig, um Werte zu übergeben und ggf. auch als Eigenschaften zu speichern, aber die grundlegende Architektur der Software sollte weitestge-hend erhalten bleiben.

Im vorliegenden Fall besitzt die Klasse Kunde eine einfache Funktion getBe-schreibung(). Sie erwartet einen Parameter, der mit Hilfe einer Fallunterschei-dung darüber entscheiden kann, welcher Art die ausgegebene Beschreibung denn sein soll. Hier ist es nun möglich, eine Text-, XML- oder CSV-Ausgabe zu erhalten.

Syntaktisch ist an dieser Klasse zunächst nichts auszusetzen. Lediglich die Tatsa-che, dass eine Fallunterscheidung für die Untersuchung eines Schaltparameters genutzt wird, wird später noch zu einer Diskussion führen. Für den Moment ist nur interessant, dass überhaupt eine Klasse entstanden ist, welche Eigenschaften und Methoden besitzt und die auch nachher für die Objektinstanziierung genutzt werden kann.

22


Kaum beschäftigt man sich allerdings mit der OOP, wird man feststellen, dass ne-ben der neuen Syntax nun eine ganz neue Welt an Programmierweisen denkbar wird. Man betritt nach der Beschäftigung mit der reinen Syntax nämlich die Welt des objektorientierten Entwurfs oder des OOP-Designs. Sinn und Zweck sollte nicht einfach nur sein, überhaupt das Schlüsselwort class zu verwenden, son-dern das eigentliche Ziel muss vielmehr darin liegen, gute objektorientierte Soft-ware zu entwickeln. Diese zeichnet sich insbesondere durch gute Wartbarkeit und Erweiterbarkeit aus – Hürden, die oftmals in prozeduralen Programmen zu sehen sind. Dieses Thema ist allerdings auch im Fokus dieses Buchs, sodass an dieser Stelle nur ein mahnender Zeigefinger genügt.

Der Aufruf der Eigenschaften erfolgt unter Verwendung des Schlüsselworts $this. Man muss es immer verwenden, wenn man Methoden oder Eigenschaften, d.h. Mitglieder der Klasse, innerhalb der Klasse selbst aufruft. Bei einer prozedura-len Funktion ist es nicht notwendig, eine besondere Syntax zu verwenden. Wenn man aber andere Funktionen verwendet, muss man innerhalb einer Klasse eine Unterscheidung treffen, ob man prozedurale Funktionen aufruft, die statische Me-thoden einer anderen Klasse sind, oder eben die Methoden der gleichen Klasse. Bei Eigenschaften ist dies etwas einfacher vorzustellen, weil man sie mit Variab-len vergleichen kann, die außerhalb einer Funktion existieren. In diesem Fall kann man innerhalb einer prozeduralen Funktion auch nicht direkt auf solche Variablen zugreifen, sondern muss sie über das Schlüsselwort global vorher ankündigen.

Es folgt nun noch der schon beschriebene Quelltext für die Klasse Kunde.

class Kunde {

// Eigenschaften

public $vorname;

public $nachname;

public $nr;

// Methoden

public function getBeschreibung($format){

if (!in_array($format, array(”xml”, ”text”, ”csv”))){

$format = ”text”;

}

switch ($format){

case ”text”:

23


return $this->vorname.” ”.$this->nachname

.” (”.$this->nr.”)”;

break;

case ”xml”:

return ”<kunde><nr>”.$this->”nr.</nr><vorname>”

.$this->vorname.”</vorname><nachname>”

.$this->nachname.”</nachname></kunde>”;

break;

case ”csv”:

return $this->nr.”;”.$this->vorname.”;”

.$this->nachname.”\n”;

break;

}

}

}

1_KundeEinfach.php: Einfache Klasse

Eine Klasse – eine Verantwortlichkeit. Mit Verantwortlichkeit meint man die Aufgabe, die eine Klasse zu erfüllen hat und für die sie erstellt wurde. Eine Klasse sollte genau eine Verantwortlichkeit be-sitzen.

Man kann, um die grundlegende Syntax der Klasse zu überprüfen, die Datei im Browser öffnen, wird aber in jedem Fall enttäuscht sein. Die erste Enttäuschung liegt vielleicht daran, dass irgendwo ein Syntax-Fehler sein Unwesen treibt. Die zweite Enttäuschung könnte darin liegen, dass bei korrekter Syntax überhaupt nichts geschieht, sondern lediglich eine leere Browser-Seite erscheint. Dies muss man sich so vorstellen, wie wenn man in PHP eine Datenbankverbindung einrich-ten will, aber nur den Fehlerfall mit einer Meldung abschließt, den Erfolgsfall je-doch zu keiner entsprechenden Erfolgsmeldung führt. Dann kann man sich auch nur dann freuen, wenn man nichts sieht – was natürlich nicht besonders aufre-gend ist.

24


Da eine Klasse nur als Vorlage, Gussform oder Schablone betrachtet werden kann, ist es notwendig, auf Basis dieser Klasse ein konkretes Objekt zu erstellen. Diesen Vorgang nennt man auch Instanziierung. Man kann auch sagen, dass man ein Ob-jekt auf Basis einer Klasse erstellt oder von einer Klasse ein Objekt erstellt. Anstelle des Begriffs Objekt kann man auch die Begriffe Exemplar oder Instanz verwenden.

Die Instanziierung erfolgt dabei mit Hilfe des new-Schlüsselworts. Man erstellt – wie sonst auch - eine Variable, der man über den Zuweisungsoperator einen Wert zuweist. Dieser Wert folgt dagegen allerdings nicht in Form eines primitiven Werts wie eine Zahl oder eine Zeichenkette, sondern wird durch new klassenname ersetzt.

Im nachfolgenden Beispiel hat man ein Objekt mit dem Namen anton erstellt, das ein Exemplar der Klasse Kunde ist. Eigentlich hat man nun in der Form $an-ton gar nicht das konkrete Objekt, sondern nur eine Referenz auf dieses Objekt im Zwischenspeicher erstellt. Die Variable $anton ist vielmehr eine so genannte Objektvariable. Andere Objektvariablen könnten ebenfalls eine Referenz auf das erstellte Objekt im Zwischenspeicher haben und bspw. die Werte in den Eigen-schaften ändern, was $anton gar nicht verhindern könnte. Für diesen Moment ist aber auch dieses Thema nur eine allgemeine Erwähnung wert, da ein späteres Beispiel es noch einmal aufgreift.

Nachdem man das Objekt erstellt hat, sind die Eigenschaften natürlich leer. Dies liegt auch daran, weil keine Logik vorgegeben wurde, welche Werte initial bei Ob-jekt-Erstellung setzt. Man kann sie nun auffüllen, indem man die Eigenschaften mit Hilfe eines Pfeil-Operators, der auch so in C++ verwendet wird, aufruft und dann einen neuen Wert mit dem Zuweisungsoperator setzt. Wie nicht anderes zu erwarten war, lautet der Wert für die Eigenschaft vorname nun Anton. Der Nachname Ebenhof könnte aus anderen Büchern schon bekannt sein: Ebenhof. Die Nummer lautet 1, da es sich ja tatsächlich um das allererste erstellte Objekt handelt. Um nun die getBeschreibung()-Methode zu testen, setzt man eine foreach-Schleife für ein Array ein, das alle drei möglichen Werte enthält, die als Formatangaben in Frage kommen.

// Objekt erstellen

$anton = new Kunde;

// Eigenschaften setzen

$anton->vorname = ”Anton”;

$anton->nachname = ”Ebenhof”;

25


$anton->nr = 1;

// Methode aufrufen

foreach (array(”xml”, ”text”, ”csv”) as $key => $value){

echo htmlspecialchars($key

.”: ”

.$anton->getBeschreibung($value))

.”<br/>”;

}

1_KundeEinfach.php: Einfache Klasse als Klient aufrufen

Nach dieser ganzen Arbeit hat man nun auch endlich ein Ergebnis im Browser, das aufgrund der Vielseitigkeit der getBeschreibung()-Methode einen umso inter-essanteren Eindruck vermittelt. Nacheinander erscheinen nämlich die gespeicher-ten Eigenschaftswerte in XML, einfachem Text und CSV.

0: <kunde><nr>1</nr><vorname>Anton</vorname>

<nachname>Ebenhof</nachname></kunde>

1: Anton Ebenhof (1)

2: 1;Anton;Ebenhof

Ausgabe im Browser

Abbildung 1.2: Klasse und Objekte

26


Nun könnte man viele andere Objekte auf Basis der gleichen Klasse erstellen. Dabei benutzt man jedes Mal die gleiche Schablone, hat aber die Wahl, andere Eigenschaftswerte zu speichern und bei Bedarf die eine oder andere Methode abzurufen, die diese Daten verarbeiten kann.

Wie bei einem assoziativen Array ist eine Reihe von Werten, die inhaltlich zu-sammenhängen, unter einem Namen versammelt. Im Gegensatz zu einem Array hingegen gibt es auch noch Verarbeitungsalgorithmen, die man ebenfalls direkt von diesem Objekt abrufen kann. Bei einem Array hätte man nur die Möglich-keit, prozedurale Funktionen zu verwenden und ihnen das Array zu übergeben. Doch dazu benötigt man noch das Zusatzwissen, dass sie genau mit einem Array mit diesen und jenen Eigenschaften sinnvoll aufgerufen werden können. Da man allerdings auch noch den Array-Aufbau in der gleichen Dokumentation notieren muss, ist zunächst viel Material vorhanden, das ein anderer Programmierer le-sen muss, um überhaupt sicher stellen zu können, dass er ein für die Funktionen verwertbares Array programmiert. Es ist zwar nicht so, dass bei der OOP plötzlich der perfekte Zustand der Selbstdokumentation ausbricht, aber wenigstens ist klar, welche Eigenschaften und Operationen verfügbar sind. Darüber hinaus ist bei der Erstellung eines Objekts schon eine Sicherung gegeben, dass die korrekten Werte zusammengesetzt werden, da nur diejenigen Eigenschaften gespeichert werden können, die tatsächlich auch in der Klasse deklariert wurden Bei einer kompi-lierenden Sprache ist der Vorteil noch größer: Einen Fehler, der auf eine falsche Nutzung der Klassen zurückzuführen ist (falsche Methoden-/Eigenschaftsnamen, falsche Parameter/erwartete Rückgabewerte), erkennt der Compiler bereits bei der Programmerstellung (und eigentlich auch schon die Entwicklungsumgebung zum Zeitpunkt der Erstellung). Es bleiben dann nur noch Laufzeitfehler übrig, die vielleicht durch logisch falsche Berechnungen erklärt werden können. Bei PHP ist dieser Vorteil nicht in diesem Maße gegeben, da durch die Interpretierung im Ge-gensatz zur Kompilierung die Fehler für den Anwender doch unmittelbar ersicht-lich sind, sofern sie nicht ausgeblendet werden.

Ein Objekt (Exemplar, Instanz) bezieht sich immer auf eine Klasse und ist eine konkrete Ausprägung ihres Bauplans. Die Erstellung kann man Instanziierung (instanziieren) nennen.

27


1. 1. 2. Konstruktoren und Destruktoren

Durch pädagogische Absicht handelt es sich bei der Klasse Kunde um eine solche Klasse, deren Eigenschaften wenigstens zum Teil immer gesetzt sein müssen. Man kann sich leicht vorstellen, wie Daten aus einem Formular übernommen werden, um ein Kunde-Objekt zu erstellen, das man dann in einer Datenbank speichert. In diesem Fall lässt sich ebenfalls leicht vorstellen, wie im Formular verschiedene Elemente mit einem Sternchen ausgezeichnet sind, um Pflichtfelder zu markie-ren, und wie ein Programm für die Formularvalidierung genau auf diese Elemente prüft. Des Weiteren dürfen diese Felder in der entsprechenden Tabelle KUNDE in der Datenbank gleichfalls NOT NULL-Felder sein. Es gibt also einige Werte, deren Existenz in jedem Fall gesichert sein muss, ohne die also ein Objekt gar nicht sinn-voll arbeiten kann.

Auch wenn man womöglich den Eindruck gewonnen hat, dass Arrays und Objekte allerhand Gemeinsamkeiten haben, und dass durch die Verwendung von komple-xen Array-Strukturen die OOP fast schon erreicht ist, so sind doch die Gemeinsam-keiten wenigstens jetzt erschöpft. Ein Array ist nämlich nicht in der Lage, Pflichtfel-der vorzugeben. Es ist ja nicht einmal möglich, überhaupt wie in einer Schablone Felder vorzugeben, ohne das Array nicht auch schon anzulegen und die Felder mit leeren Werten zu erstellen. Eine Klasse hat dagegen verschiedene Möglichkeiten, diese Pflichtfelder auch tatsächlich zu erzwingen, zu überprüfen und die Nichtbe-achtung der Regeln sogar mit einer Fehlermeldung zu belegen.

Die erste Möglichkeit, die allerdings nicht nur für die Erzwingung von Pflichtfel-dern denkbar ist, besteht in der Verwendung eines so genannten Konstruktors. Dabei handelt es sich um eine Methode, die unmittelbar ausgeführt wird, sobald ein Objekt instanziiert wird. Dabei ist es durchaus nicht notwendig oder üblich, nur Validierungen vorzunehmen. Insbesondere die Zuweisung von Parametern zu Eigenschaften der Klasse ist ein besonders häufiger Inhalt des Konstruktors sowie sonstige Initialisierung vor Vorbereitungen, die für die Nutzung des Objekts von entscheidender Bedeutung sind.

Der Konstruktor hat in PHP4 den gleichen Namen wie die Klasse. Dies entspricht der Situation, wie sie sich auch in Sprachen wie Java oder .NET stellt, wurde aber in PHP 5 geändert. Nun lautet der Standardkonstruktor __construct() mit zwei Unterstrichen zu Beginn. Die Begründung, warum dies eine bessere Lösung sein soll als der in anderen Sprachen übliche Klassenname lautet: so könne man beruhigt den Klassennamen ändern, ohne den Konstruktor ebenfalls ändern zu

28


müssen. Zudem haben alle Klassen die gleich benannte Konstruktor-Methode und passt diese zu weiteren Methoden, die mit zwei Unterstrichen beginnen.

Ein Konstruktor wird automatisch bei der Instan-ziierung aufgerufen. In PHP 5 verwendet man als Standardnamen __construct(), in PHP 4 den Klas-sennamen. Ein Destruktor mit dem Standardnamen __desc-truct() wird bei der Objektzerstörung aufgerufen.

In der geänderten Klasse Kunde gibt es nun einen Konstruktor, der die verpflich-tenden Felder, die nun auf alle Eigenschaften ausgedehnt sind und welche zu-nächst auf die richtigen Datentypen geprüft und dann schließlich den Eigenschaf-ten zugewiesen werden.

Das nachfolgende Beispiel zeigt neben dem Konstruktor auch noch den so ge-nannten Destruktor. Er ist in PHP genauso vorhanden wie in anderen Sprachen und wird mit dem Namen __destruct() (ebenfalls zwei Unterstriche) erstellt. Der Destruktor wird ausgeführt, sobald das Objekt aus dem Zwischenspeicher entfernt wird. Dies ist für PHP nicht so wesentlich, weil es außer zu schließenden Dateihandles oder Datenbankverbindungen nur wenige Gelegenheiten gibt, diese Technik sinnvoll zu verwenden. Da in anderen Sprachen, die nicht anfrageorien-tiert sind wie PHP, die Objekte für eine längere Zeit im Zwischenspeicher vorhan-den sind, kann es eine längere Zeit dauern, bis das Objekt gelöscht wird.

Dies hängt normalerweise damit zusammen, dass es im Rahmen der Software nicht mehr genutzt wurde. Bei PHP ist dies ja nicht so geregelt, weil jede Anfrage zu einem Aufbau der gesamten Objektstruktur führt und unmittelbar nach der Ab-arbeitung der Anfrage wieder gelöscht wird. Da die Klasse Kunde nicht sonderlich überladen wird und keine Datenbank- oder Dateispeicherung erfolgen sollte, folgt nur eine einfache Ausgabe, dass das Objekt zerstört wurde.

class Kunde {

// Eigenschaften

public $vorname;

29


public $nachname;

public $nr;

// Konstruktor

public function __construct($nr, $vorname, $nachname){

if (is_string($vorname) && is_string($nachname)

&& is_int($nr)){

$this->vorname = $vorname;

$this->nachname = $nachname;

$this->nr = $nr;

}

}

// Destruktor

public function __destruct(){

echo “Objekt gelöscht, kein Aufräumen sinnvoll.”;

}

}

2_KundeMitKonstruktor.php: Konstruktor und Destruktor

Nach diesen ganzen Änderungen innerhalb der Klasse ist es erforderlich, auch in der Klientensoftware Änderungen vorzunehmen. Sicherlich dämmerte schon die Frage am Horizont, wie überhaupt der Konstruktor aufzurufen ist. Man muss ge-rade die __construct()-Methode nicht selbst aufrufen, sondern setzt an den Klassennamen in runden Klammern die Parameter. Man hätte im vorherigen Kli-enten auch die Formulierung $anton = new Kunde() wählen können, denn wenn kein Konstruktor vorhanden ist, können zwar keine Parameter übergeben werden, aber dennoch ist es möglich, parameterlos die beiden runden Klammern zu verwenden.

Die Überprüfung im Klienten erfolgt über den Aufruf der Eigenschaft nr, deren Wert man ändert, um schließlich über print_r() den gesamten Objektzustand auszugeben. Schließlich unternimmt man noch den Versuch, mit ungeeigneten Parametern ein falsches Anton-Objekt zu erstellen. Dies löst zwar den Konstruk-tor aus, doch durch die Datentypvaliderung gelangen die Parameter nicht in die Eigenschaften, weswegen diese leer sind.

// Objekt erstellen

$anton = new Kunde( 1, “Anton”, “Ebenhof”);

30


// Eigenschaft abrufen und ändern

if ($anton->nr == 1) {

$anton->nr = 2;

}

// Eigenschaften ausgeben

echo “<pre>”;

print_r($anton);

echo “</pre>”;

// Objekt falsch erstellen

$anton = new Kunde(“Anton”, “Ebenhof”, 1);

// Falsches Objekt ausgeben

echo “<pre>”;

print_r($anton);

echo “</pre>”;

2_KundeMitKonstruktor.php: Konstruktor und Destruktor aus Klientensicht

Man erhält im Erfolgsfall eine gute Ausgabe der tatsächlich gespeicherten Objekt-eigenschaften, im Misserfolgsfall ein quasi leeres Objekt und schließlich in beiden Fällen die Bestätigung des Destruktors, dass die Objekte zerstört wurden.

Kunde Object

(

[vorname] => Anton

[nachname] => Ebenhof

[nr] => 2

)

Objekt gelöscht, kein Aufräumen sinnvoll.

Kunde Object

(

[vorname] =>

[nachname] =>

[nr] =>

)

Objekt gelöscht, kein Aufräumen sinnvoll.

Ausgabe im Browser

31


1. 1. 3. Zugriffsschutz und Zugriffsmethoden

Eigenschaften und Methoden kann man mit so genannten Zugriffsmodifikatoren ausstatten, welche die Sichtbarkeit für Klienten angeben. Bislang waren alle Mit-glieder immer öffentlich, d.h. die Klienten konnten Eigenschaften lesen und sch-reiben sowie Methoden aufrufen. Die Objektorientierung bietet allerdings mehr as nur das Schlüsselwort public, welches darüber hinaus ohnehin die Standar-deinstellung ist. Bei der Erläuterung der drei verfügbaren Schlüsselwörter ist es notwendig zu unterscheiden, wie die Sichtbarkeit für den Klienten (Außensicht, ein PHP-Programm, das ein Objekt instanziiert), für die Klasse selbst (Innensicht, andere Eigenschaften und Methoden der Klasse) oder mögliche Kindklassen (Ver-erbungssicht) beeinflusst wird. Das Konzept der Vererbung folgt nicht mehr in die-sem Kapitel, sodass die Darstellung der protected-Eigenschaft nur aus Gründen der Vollständigkeit vorhanden ist. Es besteht die Möglichkeit, weitere Klassen auf Basis einer (Eltern-)Klasse zu erstellen und die abgeleitete (Kind-)Klase mit zusätz-lichen Methoden und Eigenschaften auszustatten.

Abbildung 1.3: Zugriffsmodifikatoren

32


Ä Übersicht der Zugriffsmodifikatoren

Insgesamt sind folgende Schlüsselwörter vorhanden:

● public: (Öffentliche Sichtbarkeit) Klienten können von außen auf die jewei-ligen Mitglieder zugreifen. Die anderen Mitglieder können genauso auf die öffentlichen Mitglieder zugreifen. Kind-Klassen können die Mitglieder eben-falls nutzen.

● private: (Private Sichtbarkeit) Nur innerhalb der Klassen können die Mitglie-der auf die privaten Mitglieder zugreifen. Kindklassen können diese Mitglie-der nicht nutzen.

● protected: (Geschützte Sichtbarkeit) Klienten können diese Mitglieder nicht nutzen, die Mitglieder von Eltern- und Kind-Klassen dagegen schon.

Abbildung 1.4: Funktionsweise von Gettern und Settern

33


Im Zusammenhang mit dem Zugriffsschutz stellt sich automatisch die Frage, wa-rum dies überhaupt eine nützliche oder sogar sinnvolle Technik sein könnte. Am einfachsten lässt sich vorstellen, dass es Mitglieder geben kann, denen nur eine Hilfsfunktion zukommt.

Wenn man bspw. eine Klasse erstellt, welche DB-Ergebnisse in Form einer UL- und OL-Liste zurückgibt, dann ist es für die HTML-Ausgabe grundsätzlich egal, ob die Verarbeitung der Ergebnismenge bzw. die Ausführung der SQL-Anweisung in bei-den Methoden doppelt ausprogrammiert wird oder ob man eine Hilfsfunktion er-stellt, welche für die Ausgabe der LI-Elemente zuständig ist. Da es nun sicherlich kein guter Programmierstil ist, Syntaxbereiche zu wiederholen anstelle sie auszu-lagern, und Kopieren auch nicht geeignet ist, um gut wartbare Software zu erstel-len, kommt einer solchen Hilfsfunktion eine hohe Bedeutung zu. Es ist überaus nützlich, wenn Klienten diese Hilfsfunktion gerade nicht aufrufen können, denn sie können sinnvoll mit LI-Elementen ohne zugehörige Eltern-Elemente keine HTML-Ausgabe erstellen. Darüber hinaus kann es sein, dass man in jedem Fall die äußere Sicht auf die Klasse beibehalten will, um Klientenquelltext nicht ändern zu müssen, aber die Struktur der Klasse mit Blick auf Abfrageverarbeitung und Erstel-lung der LI-Elemente vielleicht doch ändern will. Je weniger Klienten über Klas-sen und die Programmierung von Algorithmen wissen, desto besser ist dies für die Wartbarkeit der Software. Der Klient soll dagegen viel eher zwei sehr schöne Methoden namens getUL() und getOL() aufrufen können, die perfekte HTML-Ausgaben erzeugen. Daher sollte man die getLI()-Methode viel besser priva-te programmieren, damit sie nur innerhalb der Klasse genutzt werden kann.

Im Laufe des Buchs werden noch verschiedene Ausführungen zum Klassendesign folgen, sodass diese Überlegungen an dieser Stelle genügen müssen. Als Regel lässt sich in jedem Fall schon einmal festhalten, dass nur so viele Informationen wie gerade eben notwendig sind, nach außen gegeben werden. Dies – und das ist nun für PHP-Programmierer, die sich gerade mit der OOP beginnen zu beschäfti-gen, eine sehr ungewöhnliche Überlegung, die sorgfältig eingeleitet werden muss – führt nun zu folgender Überlegung: Die Eigenschaften, die bislang so schön von außen sichtbar waren, sollen auch in PHP unsichtbar werden und durch so ge-nannte Getter- und Setter-Methoden ersetzt werden.

Diese Methoden – auch Zugriffsmethoden genannt – bilden die einzige Möglich-keit, auf Eigenschaften zuzugreifen, und sind in anderen Programmiersprachen gang und gäbe. In .NET gibt es neben den Feldern, die den PHP-Eigenschaften ent-sprechen, typischerweise privat sind und für die eigentliche Speicherung verwen-

34


det werden, sogar eine vereinfachte Syntax für die Abbildung von Eigenschaften. Hier ist es nicht mehr notwendig, tatsächlich in ausführlicher Syntax Getter- und Setter-Methoden zu erstellen. Inhaltlich handelt es sich dabei um Methoden, die mit den beiden Wörtern get und set beginnen und danach den Namen einer Ei-genschaft, d.h. eines Substantivs, tragen. Man deutet sie daher auch bisweilen als getXXX- und setXXX-Methoden an, wobei der Platzhalter XXX für den eigentlich abgebildeten Eigenschaftsnamen steht.

Ä Geheimnisprinzip und Kapselung

Zwei wichtige Begriffe, die im Zusammenhang mit der Verwendung von Schlüssel-wörtern wie private oder protected sowie den Zugriffsmethoden verwendet werden, sind Geheimnisprinzip und Kapselung (Verbergung).

● Das Geheimnisprinzip fasst das Konzept zusammen, dass nur die absolut notwendigen Mitglieder einer Klasse auch öffentlich sichtbar sind und dass bei Eigenschaften darüber hinaus auch festgelegt wird, ob sie sowohl lesbar als auch schreibbar sind, oder ob stattdessen nur eine von beiden Zugriffs-möglichkeiten existiert. Weil nur öffentliche Mitglieder sichtbar sind, daher genutzt werden können und Informationen über den Aufbau der Klasse nach außen geben, muss es im Umkehrschluss einen unbekannten Bereich der Klasse geben, der nicht bekannt ist. Je mehr Implementierungsdetails ver-borgen sind, desto mehr besteht die Möglichkeit, diese Details an zukünftige Anforderungen anzupassen und dadurch die Software so zu verbessern, dass die Verwendung der Klasse aus Klientensicht nicht beeinträchtigt wird. Man spricht dann davon, dass die öffentliche API konstant bleibt, während man pri-vate Mitglieder umarbeiten kann. Ein Prinzip stellt in diesem Zusammenhang einen allgemeinen Leitsatz dar, den man als Prorammierer befolgen soll. Aus den schon mehrfach genannten Gründen der Wartbarkeit und Erweiterbar-keit ist daher dieses Prinzip anzuwenden, um durch möglichst viel verborgene Implementierungsdetails offen für Änderungen und Erweiterungen zu sein.

● Die Kapselung hängt eng mit dem Geheimnisprinzip zusammen und könnte je nach Lesart sogar als Synonym gelten, wenn man diesen Begriff ebenfalls mehr als Leitsatz betrachtet. Wenn man eine Eigenschaft bspw. nur mit Hilfe von Getter- und Setter-Methoden aufrufen kann, dann ist die eigentliche Ei-genschaft gekapselt, d.h. verborgen. Kapseln ist dabei der Fachbegriff für den Vorgang, ein Implementierungsdetail zu verbergen. Man verwendet dabei

35


immer wieder eine solche Formulierung wie „XY ist gekapselt“, womit man den Umstand bezeichnet, dass man nur über Zugriffsmethoden Zustände abfragen oder ändern kann. Man kann diese Formulierung auch auf solche Situationen anwenden, wenn komplexe Datenstrukturen oder mehrere Fel-der, die zusammengehören wie bspw. ein Datum (Tag, Monat, Jahr) oder eine Adresse (Straße, PLZ und Stadt) in einer Klassse abgebildet werden und man direkt nicht mehr die einzelnen Felder verwenden kann, aber durch die Kapse-lung sicher stellt, dass die drei Felder tatsächlich zusammengehören und auch zusammen zum Einsatz kommen. Setzt man Softwarekomponenten ein, dann kann man hier auch davon sprechen, dass ein bestimmter Bereich wie eine Datenbankschnittstelle, ein Prozessor für die Verarbeitung von XML-Daten o.ä. in einer Klasse gekapselt ist und je nach Konfiguration durch unterschied-liche konkrete Software-Komponenten ersetzt werden kann (Treiberkonzept).

In PHP lassen sich die Konzepte der Objektorientierung, die in anderen Sprachen seit Jahren genutzt werden, ebenfalls syntaktisch umsetzen. Als Einschränkung muss man allerdings hier hinzusetzen, dass natürlich das Geheimnisprinzip eher aus der Sicht eines Klienten nachvollziehbar ist. Da in PHP gar keine Komponenten möglich sind und nicht einmal Programme kompiliert werden können, kann sich jeder Programmierer, der über eine include-Anweisung andere Dateien und da-mit Klassen einbindet, auch in Erfahrung bringen, wie diese programmiert sind. Er kann nicht nur alle Implementierungsdetails sehen; er ist sogar in der Lage, die genaue Programmierung zu ändern und private Mitglieder einfach zu veröf-fentlichen. Dies zeigt nicht, dass das Prinzip an sich zu kritisieren ist, sondern ist nur eine Vereinfachung in PHP, die – wie viele andere Vereinfachungen ebenfalls – nicht zum Nachteil für die PHP-Technologie an sich ausgenutzt werden sollten.

Ä Getter- und Setter-Methoden

Nach dieser kleinen Einführung in die Überlegungen der Kapselung folgt nun eine kurze Darstellung der Zugriffsmethoden, die in wesentlicher Weise das Geheim-nisprinzip umsetzen helfen:

● Eine Getter-Methode hat keine Übergabe-Parameter. Sie liefert den Wert einer ansonsten privaten Eigenschaft zurück. Weil der Lesezugriff in einer eigenen Methode gekapselt ist, kann man über die Einrichtung einer solchen Metho-de auch steuern, ob eine Eigenschaft überhaupt lesbar ist oder nicht. Die-

36


se feine Unterscheidung ist mit dem einfachen public-Schlüsselwort nicht möglich, da hier sowohl Lese- als auch Schreibzugriff zugelassen werden. Ein-fache Getter-Methoden bestehen einfach nur aus einer return-Anweisung, welche den gespeicherten Eigenschaftswert zurückliefert. Erweiterte Getter-Methoden jedoch erlauben es, Daten bei der Rückgabe zu formatieren, aus verschiedenen einzelnen privaten Eigenschaften zusammenzusetzen oder auf beliebige Weise umzuwandeln. Ein typisches Beispiel ist immer wieder die Unterscheidung zwischen Netto- und Bruttopreis von Produkten. In zwei privaten Eigenschaften speichert man den Mehrwertsteuersatz und den Net-topreis. Die Getter-Methode für den Nettopreis liefert den einfachen Wert der Nettopreis-Eigenschaft zurück. Die Getter-Methode für den Bruttopreis dagegen liefert nicht den Wert eines fest gespeicherten Bruttowerts zurück, sondern rechnet diesen mit Hilfe des Steuersatzes (bspw. 19) aus: return $this->netto*(1 + $this->steuersatz/100). Dadurch ist es möglich, nach außen quasi Eigenschaften anzubieten, die gar nicht als tatsächliche pri-vate Eigenschaft auch vorliegen.

● Eine Setter-Methode hat dagegen genau einen Parameter, welcher den neuen Wert einer Eigenschaft enthält. In einer einfachen Version weist man diesem Wert einfach nur den der privaten Eigenschaft zu: $this->steuersatz = $steuersatz. In einer erweiterten Methode kann man hier auch nur Daten-typüberprüfungen oder sonstige Validierungen und Umrechnungen durch-führen, ehe der Wert endgültig gespeichert wird. Sofern eine Setter-Methode vorhanden ist, besitzt der Klient die Schreiberlaubnis auf die ihr zu Grunde liegende Eigenschaft. Das einfache Schlüsselwort public dagegen erlaubt immer gleichzeitig Lese- und Schreibzugriff.

Erstellen Sie Getter-/Setter-Methoden, um den Zu-griff auf Eigenschaften zu gewähren. So kann man Überprüfungen und Umwandlungen realisieren, Lese-/Schreibzugriff getrennt verwalten und zusät-zliche Zustandswerte nach außen anbieten, die aber nicht fest gespeichert werden. Verwenden Sie die Zugriffsmethoden auch intern.

37


Es gibt deutlich mehr Vorteile, eigene Zugriffsmethoden zu verwenden anstatt Ei-genschaften öffentlich zu gestalten. Nachteilig ist lediglich der Schreibaufwand, der leider gerade im PHP-Bereich erheblich ist, weil nur wenige große Entwick-lungsumgebungen eine Werkzeugunterstützung für die Erstellung von Getter- und Setter-Methoden anbieten. In einer solchen IDE ist es möglich, aus dem Kontext-menü einen Eintrag zur automatischen Erstellung von Zugriffsmethoden für die vorhandenen Eigenschaften aufzurufen und dabei noch durch Kontrollkästchen anzugeben, welche Zugriffsmethoden für die verschiedenen Eigenschaften kon-kret zu erstellen sind. Hat man eine solche IDE nicht zur Verfügung, bleibt nichts anderes übrig, als tatsächlich diese Methoden selbst zu erstellen.

Ein oftmals gehörtes Argument, man könnte ja auch beide Formen mischen, stellt sich vielleicht nicht in jedem konkreten Fall unmittelbar als verwerflich dar, führt aber bei einer langfristig angelegten Software zu Schwierigkeiten. Eine solche Mi-schung sieht vor, dass die Eigenschaften, von denen man heute weiß, dass keine Validierungen, Umwandlungen oder besonders feine Zugriffsrechte notwendig sind, als öffentlich markiert werden, während andere Eigenschaften und insbe-sondere Getter-Methoden, die aus Bequemlichkeits-/ Komfortgründen erstellt werden, in Form von eigenen Methoden implementiert werden. Dies erschwert die Benutzung umso mehr, weil man bei der Erstellung der Klientensoftware wis-sen muss, welche Eigenschaften wie implementiert sind. Änderungen sind auch nur schwer möglich, da ja nicht einfach öffentliche Eigenschaften auf privat ge-setzt werden können, ohne nachzuvollziehen, wer den öffentlichen Zugriff denn tatsächlich nutzt.

Ä Beispiel

Nach diesen ganzen Vorreden und Überlegungen ist es schwierig, ein besonders aufregendes Beispiel zu finden, zumal die Erstellung von Zugriffsmethoden mehr ein philosophisches als ein syntaktisches Problem darstellt. Die Klasse Kunde än-dert man also im nachfolgenden Beispiel so ab, dass alle Eigenschaften nun pri-vat sind. Dann folgen für Vor- und Nachname beide Methodenarten, während die Nummer nur lesbar ist, weil man sich vorstellen kann, dass diese Nummer durch eine Speicherung in der Datenbank, die ebenfalls in dieser Klasse durchgeführt wird, ermittelt wird und von außen sinnvoll nicht gesetzt werden kann. Dann gibt es noch eine Getter-Methode, die einen zusammengesetzten Namen zurückliefert – eine typische Komfortmethode, die Klienten häufige Arbeit ersparen soll.

38


class Kunde {

// Private Eigenschaften als reiner Wertespeicher

private $vorname;

private $nachname;

private $nr;

// Konstruktor

public function __construct($nr, $vorname, $nachname){

$this->setVorname($vorname);

$this->setNachname($nachname);

$this->setNr($nr);

}

// Getter- und Setter-Methoden

// Vorname und Nachname sind les- und schreibbar

public function getVorname(){

return $this->vorname;

}

public function setVorname($vorname){

if (is_string($vorname))

$this->vorname = $vorname;

}

public function getNachname(){

return $this->nachname;

}

public function setNachname($nachname){

if (is_string($nachname))

$this->nachname = $nachname;

}

// Nr ist von außen nur lesbar

public function getNr(){

return $this->nr;

}

// Name ist von außen nur lesbar

// und wird nur erzeugt, nicht gespeichert

public function getName(){

return $this->getVorname().” ”.$this->getNachname();

}

}

3_KundeMitGetternSettern.php: Getter- und Setter-Methoden

PHP: OOP, Design Patterns und UML - Comelio · PDF file18 1.1 Einfache Klassen 1. 1. Aufbau...

Documents

Transcript of PHP: OOP, Design Patterns und UML - Comelio · PDF file18 1.1 Einfache Klassen 1. 1. Aufbau...