PHP - Objektorientiert oder Nicht - Mit oder ohne Framework
Hallo,
ich stehe gerade vor einem PHP-Projekt und bin am überlegen wie das ganze angefangen werden soll.
Soll ich das Projekt Objektorientiert oder Nicht und mit oder ohne Framework entwickeln??
Ich habe früher in einem größeren PHP basierenden ERP-System gearbeitet. Dieses ERP-System war schon älter und nicht objektorientiert programmiert. Ich habe mich auch schon mit dem Zend-Framework 1und2 beschäftigt. Ich finde es aber sehr umständlich und ich habe das Gefühl, dass es so viel viel länger dauert zu entwickeln. Welchen Vorteil hat ein Framework genau? Macht es Sinn eins zu verwenden?
Angenommen ich verwende kein Framewokr - wie entwickle ich PHP dann Objektorientiert? Muss ich ein MVC-Pattern programmieren?
1 Antwort
Das MVC-Pattern ist letztlich nur eine Möglichkeit um die Anliegen zu trennen und z.B. die aufbereiteten Daten über verschiedene Views auszugeben.
Was Frameworks betrifft, die sollen ein eben die Strukturierung abnehmen. Ein wirklich großes Projekt mittels MVC von anfang an aufzuziehen ist wahnsinn. Neben Zend gibt es aber auch andere Frameworks. Früher war CodeIgniter sehr beliebt, mittlerweile is Laravel wohl das beliebteste, da es Gebrauch macht von Closures usw. und im Aufbau beliebten JavaScript Frameworks wie jQuery ähnelt.
Mit OOP siehts ähnlich aus. Das war ganz einfach ein Konzept, das mit dem Problem aufgekommen ist, dass Code nicht wiederverwendet wird und immer wieder alles neuentwickelt wird. Man hat eben eine entsprechende Datenkapselung, kann Objekte vererben usw. Mittels Interfaces und co. sind gleichartige Objekte austauschbar.
Frage ist natürlich immer wofür man etwas benutzt. Für eine Funktion die z.B. etwas sortiert oder einen Durchschnitt wiedergibt, brauch es natürlich keine Klasse. Für etwas das Zustände hält, ggf. mehrfach da ist bzw. wovon wir mehre Instanzen benötigen oder leichte Abwandlungen hat (Vererbung) ist OOP natürlich sehr hilfreich.
OOP nur dem OOP wegen macht aber wenig Sinn. Viele stopfen einfach alles in eine Klasse und nennen es dann OOP. Zu OOP gehört imo mehr dazu, das ganze Design des Programms bzw. der Objekte muss so gestaltet werden, dass man durch OOP auch die entsprechenden Vorteile hat. Hier mal ein entsprechendes Tutorial:
Ansonsten was Frameworks und co. angeht ist natürlich noch hinzuzufügen, dass etwas selbst ausgedachtest oft nicht so gut kommentiert ist, andere Leute sich erstmal einarbeiten müssen usw. Während entsprechende Frameworks einfach ein Standart sind, viele Leute dieses beherrschen, fertige Lösungen vorhanden sind, andere Leute auf selbe Probleme gestoßen sind, eine entsprechende Dokumentation für die API da ist usw. Kurz es macht das Arbeiten in Teams ebenfalls erheblich leichter.
Wenn hinter dem Programm eine ordentliche Struktur stehen soll, dann dauert das immer länger. Frameworks zwingen dich halt quasi gerade zu dazu. Dafür macht es das Endprogramm meist leichter erweiterbar bzw. wartbar.
Letztlich würde ichs aber immer von dem Projekt abhängig machen, das richtige Werkzeug für den Job eben. Und nicht immer den Hammer, weil man den Hammer am tollsten findet. Das mag zwar zum Nägel in die Wand schlagen ganz toll sein, wenn der Zahnarzt aber zur Spritze und dem Bohrer greift (auch wenn das ebenfalls nicht toll ist) sind wir doch glücklich darüber, dass er das angebrachte Werkzeug benutzt und nicht sein Lieblingswerkzeug, den Hammer, egal ob er in der Situation angebracht ist oder nicht.