Artikelformat

Die Modifiers in PHP – Teil 1

Damals – als wir noch mit PHP4 unterwegs waren – gab es keine Modifier. Alle Attribute und Methoden einer Klasse waren grundsätzlich public und man behalf sich mit Konstruktionen wie „Methoden, die mit Unterstrich anfangen, sind private“. Dies muss aber nicht sein und mit PHP 5 gibt es mehrer Modifier, die das Entwicklerherz höher schlagen lassen. Diese sind public, private, protected und abstract, final. Hier gibt es nun eine kleine Beitragsreihe, die die Modifier vorstellt und an Beispielen erklärt. Beginnen wir mit dem aus PHP4 übernommenen, dem public-Modifier.

Der public-Modifier kann explizit angegeben werden oder man kann ihn auch weglassen. Ich persönlich gebe den Modifier explizit an. Einerseits unterstützen morderne IDEs die Entwicklung mit den Modifiern, andererseits kann ein zweiter Programmierer direkt sehen, dass ich eine Methode aus Absicht public deklariert habe und nicht einfach nur vergessen habe den Scope zu setzen.
Public-deklarierte Methoden kann man nun immer aufrufen und in abgeleiteten Klassen natürlich auch nutzen. Daneben darf man die Methode überschreiben. Bei Attributen wirkt public so, dass man direkt auf die Attribute von außen zugreifen kann. Dies ist normalerweise nicht gewünscht. Man nutzt hier üblicherweise Setter und Getter, damit man die Möglichkeit hat, Daten vor dem Speichern im Attribut zu validieren (z.B.). Bei einem direkten Zugriff funktioniert dies nicht. Der Trick mit dem magic __get und __set kann dies zwar auch bewerkstelligen, wird aber schnell unschön, wenn verschiedene Attribute verschieden Validatoren benötigen.

Als Beispiel packe ich wieder mal ein paar Autos aus:

1
2
3
4
5
6
7
8
9
10
11
class car {
    public $engine
 
    public function start() {
         $engine->start();
    }
}
 
$myCar = new Car();
$myCar->engine = null;
$myCar->start();

Wir haben nun ein Auto mit einem Motor. Da der Motor public ist, kann er auch durch Luft (oder einfach nichts) ersetzt werden. Startet man das Auto, fällt die Anwedung auf die Nase und man hat schon den beschriebenen Fall. Hätten wir einen private Modifier, könnte man den Motor durch den Zugriff von außen schützen und das sehen wir im Beitrag Teil 2.

2 Kommentare

  1. Wie handhabst Du das private/public bei member Variablen? Es gibt ja auch Fälle, z.B. bei reinen Datenobjekten, wo es nicht wirklich Sinn macht, etwas private zu machen.

    Hast Du Beispiele, wo du member Variablen public machst (der Normalfall ist ja private/protected).

    Antworten
    • In den Projekten, bei denen ich bisher mitgearbeitet habe, gab es keine public Attribute (oder Member Variablen). Datenobjekte bieten sich natürlich an, aber die waren bisher immer mit der Datenbank verknüpft und die der ORM-Layer möchte informiert sein, wenn sich das Datenobjekt ändert. Dies kann man intern durch __set und __get erreichen. Von außen sieht alles immer noch so aus, als wären die Attribute public. An dieser „Tradition“ würde ich festhalten, da man bei PHP keine Typ-Sicherheit hat und die einzelnen Attribute kontrolliert befüllt werden sollten.

      Einen Sonderfall unterstütze ich natürlich. Wenn man Bibliotheken nutzt um bspw. einen Webservice anzusprechen, erhält man ganz gerne PHP-Objekte zurück, die komplett public sind. Ist ja nicht tragisch, aber eben eher die Ausnahme von der Regel.

      Mein Vorgehen ist auch daher geprägt, da ich auch Java-Entwickler bin und einige der PHP-Kollegen aus der Java-Ecke kommen. Dort ist es ganz normal mit Gettern und Settern zu arbeiten. Die beiden oben genannten magischen Methoden sind ja auch nichts anderes als universelle Versionen.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.