• Vorträge

    Viele Vorträge, die auf Konferenzen gehalten werden, landen irgendwo im Internet. Wir haben sie für euch zusammengesucht.

    • Open-Closed-Prinzip

    von am 15. März 2010

    Wieder zurück in der Hansestadt nach einer Woche Urlaub im Schnee. Als erstes möchte ich mich natürlich bei meinen Co-Autoren bedanken, für fünf wirklich gute Artikel. Die Statistiken munkeln sogar so was wie „die beste Woche“ bisher. Also nochmal vielen Dank dafür. Jetzt aber wieder zum Ernst des Lebens … der Softwaretechnik. Leider kann ich bei diesem Artikel nicht aus anderen Quellen zitieren, da ich gerade kein Internet habe, aber ich versuche das mal auf eigene Faust und schreibe wild drauf los.

    Im Open-Closed-Prinzip geht es darum, dass man seinen Code immer so schreibt, dass er offen für Erweiterungen (open) ist und geschlossen für Änderungen (closed). Das klingt jetzt vielleicht erstmal paradox. Erweiterungen und Änderungen sind doch eigentlich fast das gleiche oder gehen zumindest Hand in Hand. Deswegen erläutern wir das am besten mal ein wenig genauer. Falls etwas offen für Erweiterungen ist, so kann ich jederzeit neue Funktionalitäten hinzufügen ohne Probleme zu bekommen. Wenn ich diese Funktionalität einsetze, so ist es wichtig, dass ich bestehende Schnittstellen damit nicht beeinträchtige. Es darf sich also nach außen nichts verändern. Ich bin also geschlossen für Änderungen.

    Eine Klasse, ein Modul oder ein Service ist also besonders gelungen, falls ich ihn erweitern kann, ohne das Konsumenten diese Erweiterung mitbekommen, sie aber trotzdem bei Bedarf nutzen können. Besonders wichtig ist dieses Prinzip falls man öffentliche Bibliotheken bereitstellt. Stellt euch mal vor, dass das Zend Framework bei jeder Erweiterung Schnittstellen anpassen würde und ihr euren kompletten Code umbauen müsstet, damit er weiterhin funktioniert. Wäre doch echt kacke!

    Ich würde mal sagen, dass ich in der nächsten Zeit ein paar Beispiele mitbringen werde, damit wir darüber diskutieren können, wie man dieses Paradigma am effizientesten umsetzt. Bis dahin hoffe ich dem ein oder anderen ein neues Buzzword beigebracht zu haben.

    Nils Langner

    Auch wenn Ihr es mir nicht glauben werdet, aber ich habe nichts gegen PHP. Ich rege mich einfach nur gerne auf. Ok so schlimm ist es auch nicht. Eigentlich wollte ich schon immer einen Blog haben und da ...

    Zum Profil von Nils Langner

    9 Kommentare »


    • Sebastian
      am 15. März 2010 um 08:45 Uhr

      Ich werfe mal das Decorator Muster in den Raum. Passt ziemlich gut dazu, würde ich sagen


    • Dennis Becker
      am 15. März 2010 um 08:47 Uhr

      Hmm… solange ich eine Schnittstelle erweitere, sagen wir mal, ich brauche einen weiteren Parameter, kann ich den ja so einbinden, dass bestehender Code nicht angepasst werden muss. Würde man das auch unter Erweiterung einordnen?


    • Nils Langner
      am 15. März 2010 um 08:57 Uhr

      @Sebastian: Guter Wurf (http://www.phphatesme.com/blog/softwaretechnik/php-entwurfsmuster-decorator/)

      @Dennis: Mit optionalen Parametern geht das. Ich finde aber, diese Parameter machen den Code irgendwann unlesbar. In “Clean Code” wird zum Beispiel beschrieben, dass eine Methode maximal zwei Parameter haben sollte und wird da auch schlüssig erklärt. Ich bekomme es leider nicht mehr 100% zusammen, kann es aber vll. mal nachreichen.


    • Tom
      am 15. März 2010 um 09:45 Uhr

      Okay – also es geht um das Erweitern einer Klasse ohne gezwungen zu sein deren Quelltext zu ändern. Also wohl zurück zu den Basics?

      Where is the bacon?


    • Nils Langner
      am 15. März 2010 um 09:51 Uhr

      @Tom: Das hast du falsch verstanden. Du darfst den Quelltext der Klasse ändern, nur die Nutzer der Klasse sollen ihn nicht ändern müssen.


    • PHPGangsta
      am 15. März 2010 um 13:53 Uhr

      Das ganze geht auch in Richtung Interfaces. Wenn ich meinen Code immer gegen stabile Interfaces programmiere, werde ich auch dazu erzogen, mir vorher tiefgründige Gedanken über die Funktionen und Parameter zu machen, und diese im späteren Code-Leben nicht verändern zu müssen.
      Sollte ich eine Klasse erweitern müssen, kann ich mir überlegen sie entweder gegen ein zweites Interface zu programmieren oder das ursprüngliche Interface zu erweitern.


    • Marc Binder
      am 15. März 2010 um 21:21 Uhr

      Wobei die Erweiterung eines vorhandenen Interfaces auch nicht immer ohne weiteres möglich ist.


    • Julian
      am 15. März 2010 um 22:12 Uhr

      Das Stichwort “Modularisierung”, auch innerhalb von Klassen im Bereich der Objektorientierung spielt für mich hier auch eine wichtige Rolle, um einfacher in Abläufe eingreifen zu können.


    • • Warum Separation of Concerns vielleicht das wichtigste Paradigma von allen ist | test.ical.ly
      am 17. März 2010 um 05:12 Uhr

      [...] Entwicklung zu gewährleisten. Auf PHP hates me gab es dazu gerade einen schönen Artikel über das Open-Closed-Prizip. Aber inwieweit können die oben genannten Paradigmen helfen, so ein Prinzip [...]

    RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

    Hinterlasse einen Kommentar

    Werbung
    PHP Magazin
    Ausgabe 02/2010

    Dieses Mal mit Artikeln zu den Themen OpenSocial und Apache Shindig, Graphentheorie, Smarty3

    t3n
    Ausgabe 19

    Social Media (R)evolution. Weitere Themen sind noSQL, Crowdsourcing ...

    PHP Journal
    Ausgabe 2/2010

    PHP & Windows optimal nutzen, die besten PHP-CMS im Überblick, Google-API mit Zend Framework nutzen.

    Wir wurden schon öfters gefragt, ob man uns nicht irgendwie unterstützen kann. Die Antwort war immer einfach: Klar! Am einfachsten ist es eure nächsten Einkäufe bei Amazon über unsere Link abzuwickeln. Damit würdet ihr uns schon sehr helfen. Über Co-Autoren freuen wir uns aber noch mehr.