abstrakte Klassen

Pherseus

Erfahrenes Mitglied
Hallo,
ich versuche gerade OOP mit PHP5 zu verstehen. Dabei bin ich nun bei abstrakten Klassen angelangt. Ich lese dazu folgenden Artikel http://www.professionelle-softwaree...erste_auflage/oop.foundations.interfaces.html

Was eine abstrakte Klasse bzw. eine Schnittstelle ist, habe ich soweit verstanden. Auch wie sie angelegt und benutzt werden. Jedoch ist mir der Sinn davon nicht so ganz klar, bzw. wofür man sie verwenden sollte. In dem Text ist ja auch ein Beispiel.

Warum werden die Klassen Obst bzw. Gemüse als abstrakte Klassen deklariert. Man könnte sie doch auch als normale Klasse benutzten.

Und warum sind entsaftbar und rollbar als schnittstellen definiert, wenn man hinter sowieso die methode in der jeweiligen klassen programmieren muss? Welchen Vorteil hat das?
 
Hallo,

wusste gar nicht das es das Buch auch online zu lesen gibt, habs hier als Printausgabe zu liegen :-)

Also zum Thema, mal ganz grob gesagt:

- abstrakte Klassen dienen dazu die Abstammung festzulegen, im Beispiel also ist die Klasse "Tomate" von der Art "Gemuese".

- Schnittstellen dienen dazu, die Funktionalitäten festzulegen, ohne die eigentlichen Methoden zu definieren. Somit kannst du über Schnittstellen dafür sorgen das verschiedene Klassen die eine Schnittstelle implementieren sich gleich bedienen lassen, da ihnen über das Interface die Methodennamen und Signaturen (also Parameterreihenfolgen etc.) festgelegt sind. So ruft sich zum Beispiel in den jeweiligen Beispielen die Methode "entsaften" immer gleich auf. Man guckt also nur noch, ob die Klasse das Interface "Entsaftbar" implementiert und weiß dann schon wie sie zu bedienen ist. Aber wie das konkrete Entsaften aussieht, dass ist dann wieder der jeweiligen Klasse überlassen (man entsaftet ja nicht jedes Obst/Gemüse auf die gleiche Weise)

Im Großen und Ganzen ist beides also kein Muss, man KANN es auch anders lösen. Allerdings sorgt ein sauberes Codedesign mit sinnvollen Abstammungen und Schnittstellendefinitionen für einfacheres Debugging, leichtere Fehlerbehandlung und auch nicht zu letzt zu erheblich verbesserter Codelesbarkeit, nicht nur für Fremde sondern auch für einen selbst. Vielleicht kennst du ja den Effekt, dass du dir ein eigenes Projekt nach einem Jahr oder mehr nochmal ansehen sollst ... da muss man dann, auch wenn man der eigentliche Programmierer ist, sich auch erst wieder reinfinden. Je sinnvoller die Struktur ist, desto einfacher und kürzer ist diese Prozess.

Hoffe ein wenig Klarheit geschafft zu haben :-)

Nachtrag:

stell dir vielleicht stellvertretend das Ganze noch mit einem Obst und einem Gemüsehändler vor.

PHP:
<?php

// verkauft Gemüse ...
class GemueseHaendler {
    public function kaufeEin(Gemuese $ware)
    {
        // mach was mit dem Gemuese
    }
}
?>

der Gemuese-Händler kauft also $ware ein ... per "TypeHint" sorgst du dafür, dass die eingekaufte Ware auf jeden Fall von der Art "Gemuese" sein muss ... denn es ist ja ein Gemüsehändler. Wenn du dem also eine Banane unterschieben willst, wird PHP meckern. Das Hilft beim Entwickeln, da es nun dir schwerer ist, den Methoden falsche Daten zu übergeben (auch wenn PHP leider nur bei Objekten und Arrays TypeHints erlaubt) und ein externer Entwickler sieht sofort, was beim Methodenaufruf erwartet wird.

Und vielleicht noch ein Beispiel zu Schnittstellen: Guck dir die String-Funktionen bei PHP an. Mal heißen sie "str_repeat", im nächsten Moment gibt es kein _ im Funktionsnamen, es heißt also z.B.: "strpos" ... und dann noch die Reihenfolge der Paramter, selbst ein erfahrener PHP-Entwickler muss des Öfteren mal nachgucken wie jetzt genau die Reihenfolge war. Mit Hilfe von Interfaces kannst du dem Problem entgegen wirken. Du legst in einem Interface für eine Klasse fest wie die Methoden heißen, und in welcher Reihenfolge und auch was für Paramter die Methode erwartet. Du sorgst also dadurch für eine konsistente Bedienung deiner Klasse. Ein gutes Beispiel dafür sind auch Datenbank-Abstraktions-Klassen. Bei denen macht es auch Sinn das die jeweiligen Treiberklassen für die jeweiligen Datenbanken ein Interface implementieren, sodass sich die Klasse auf jeden Fall, egal ob MySQL, PostgreSQL oder Oracle komplett gleich bedient (das ist ja auch der Sinn der DB-Abstraktion).

So, nun aber Bettzeit, gute Nacht :-)
 
Zuletzt bearbeitet:
Zurück