Abstraktion, Kapselung und Wiederverwendbarkeit... Das sind so in etwa die Grundpfeiler der objektorientierten Programmierung und werden wohl auch überall erwähnt. Letztenendes ist es eine Sache dessen, wie man was machen möchte: Niemand zwingt dich zur Objektorienterung, wenn du es für nicht nötig erachtest.
Der reelle Nutzen kommt dann, wenn du diverse Applikationen schreiben musst, die irgendwie immer etwas gemeinsam haben, bei denen aber trotz spezieller Probleme immer neue und andere Funktionen erfordern, oder weitere Eigenschaften hinzukommen. Des Weiteren hat man in einer Klasse normalerweise bestimmte Bestandteile gekapselt, die von Außen nicht erreichbar sind und somit ein Überschreiben unmöglich wird.
Statt einem global Schlüsselwort wird eine Referenz auf die Instanz verwendet, statt der Speicherung der Werte im Global Scope, findet dies instanzintern getan.
Nehme man zB mal eine Mail-Klasse als triviales Beispiel: Man beginnt normalerweise bei einer einfachen Funktion, wie
PHP:
function mail( $from, $to, $subject, $message, $headers = null ) {
// ... tue was
return $success;
}
Was aber, wenn man ein wenig mehr Kontrolle möchte? Wie soll man dann eine Funktion gestalten?
PHP:
function mail_factoringTo( array $to ) {
return implode( ', ', $to );
}
function mail( $from, ... ) { ... }
Und nun wollen wir noch eine Überprüfung einbauen, ob auch alle Adressen valide sind:
PHP:
function mail_checkAdressValidity( $mail ) {
return 1 === preg_match( "%^pattern$%Ui", $mail );
}
function mail_factoringTo( array $to ) {
if ( 0 < count( $args = func_get_args() ) ) {
$return = array_pop( $to );
while ( null !== ( $current = array_pop( $to ) ) && mail_checkAdressValidity( $current ) ) {
$return .= $current;
}
return $return;
} else {
return null;
}
}
Und so weiter. Irgendwann landen wir dann bei:
PHP:
<?php
mail( $from, mail_factoringTo( $arrayTo ), $subject, $message );
Und dann fällt uns auf, dass wir mal Carbon Copies und Blind ~ benötigen könnten, oder dass der Versand auch über SMTP funktioneren soll. Alle Funktionen umschreiben? Warum nicht gleich mal ein wenig nachgedacht und abstrahiert?
PHP:
<?php
abstract class Mail_Abstract {
protected $_from = "";
protected $_to = array();
protected $_cc = array();
protected $_bcc = array();
protected $_subject = "";
protected $_message = "";
protected $_headers = array();
/**
* Konstruieren des To-Parts
*
* @return String
*/
protected function _getTo() {
return implode( ', ', $this->_to );
}
// ...
/**
* Füge Empfänger hinzu, gibt Referenz auf $this für Fluent Interface zurück.
*
* @param String $mail
* @param String $name
* @return Mail_Abstract
*/
protected function addRecipient( $mail, $name = null ) {
// Wenn Adresse gültig ist, füge sie dem Stapel an
if ( self::isValid( $mail ) ) {
// ...
}
return $this;
}
/**
* Gibt zurück, ob eine Adresse valide ist
*
* @param String $mail
* @return boolean
*/
public static function isValid( $mail ) {
return 1 === preg_match( "%^pattern$%Ui", $mail );
}
/**
* Wird in einer konkreten Klasse überschrieben und dient der entsprechenden Deklaration, wie gesendet wird
* Da SMTP zB anders funktioniert als die PHP-interne mail() Funktion, lassen wir es an dieser stelle abstrakt.
*
* --> Polymorphie
*/
abstract public function send();
}
class Mail extends Mail_Abstract {
/**
* Konstruiere weitere Header
*
* @return String
*/
protected function _getHeaders() {
$string = "From: {$this->_from}\n\r";
// ...
return $string;
}
/**
* Überschriebene send() Methode
*
* @return boolean
*/
public function send() {
return mail( $this->_getTo(), $this->_subject, $this->_message, $this->_getHeaders() );
}
}
Aufruf in diesem Fall über das flüchtige Interface zB:
PHP:
$mail = new Mail()
->addTo( "foo", "bar" )
->addTo( "bla" )
->addSubject( "test" )
->addMessage( "..." )
->send();
Sehr unvollständig und trivial, sollte aber in etwa die Funktionalität darstellen können.
Der Zwang zu verstehen, was OOP ist, lohnt sich nicht. Es ist nur ein Paradigma von vielen, und auch nur eine Möglichkeit von vielen. So lange man nicht selbst auf die Idee der Kapselung kommt, kann man auch die OOP nicht verinnerlichen, denn dann wird es in der Tat nur eine Sammlung von vielen statischen Methoden oder eine zu spezielle Abbildung und Ansammlung dynamischer Methoden.
