Verständnigsfrage zu OOP in PHP

**Master0Blicker** · 28.03.2017, 09:59

Niemand der mich etwas aufklären kann?
Berichtet mir doch lediglich wie ihr das macht.
Arbeitet ihr nur objektbasierend oder eine Kombination aus prozedualem Code + Klassen/Objekte (Prozedualer Code in PHP-Datei + Objekte für bestimmte Dinge wie Datenbanken, Mailversand, Bildbearbeitungen usw..)?

Ich stelle mir das am saubersten als reine OOP vor wo jeder Bereich, jeder DIV-Container, jede Liste in Klassen ausgelagert wird wessen Methoden das an Ort und Stelle generieren.
Und in dieser Vorgehensweise stellt sich die Frage wie die Objekte aufgeteilt werden. Eine Gott-Klasse die wiederum andere Klassen enthält die sich um die einzelnen Elemente kümmern, eine Gott-Klasse die sich selber um die einzelnen Elemente kümmert (-> jeder Bereich/Element als eigene Funktion/Methode, was ich mir schwer vorstellen kann) oder doch das Root-Dokument (PHP-Datei) als Basis und in dieser wimmelt es von den einzelnen Objekten die die einzelnen Bereiche/Elemente der HTML-Datei generiert?

Beispiel 1, reine OOP:

PHP-Code:


<?php

    class LoginClass {

        public $status = 0;

        public $lastLogin;

        private $LoginVersuche = 0;

        

        public function Login($username, $password)

        {

            mach_irgendwas();

            #usw.

        }

        

        public function showLogin()

        {

            erstelle_Login_Formular();

            #usw.

        }

    }

    

    class Title

    {

        private $title;

        

        function __construct($title) {

               $this->title = $title;

           }

        

        public function createTitle()

        {

            echo sprintf("<title>%s</title>", $this->title);

        }

    }

    

    class HTML

    {

        

        private $css_ref;

        private $objTitle;

        private $objLogin;

        #usw.

        

        function __construct($title) {

             $this->objTitle= new Title($title);

        }

        

        public function setCSSRef($path_css)

        {

            $this->$css_ref = $path_css;

        }

        

        public function createHead()

        {

            echo "<head>\n";

            objTitle->createTitle();

            echo sprintf("<link rel='stylesheet' href='%s'>\n", $this->css_ref);

            echo "<head>\n";

        }

        #usw. viele weitere Funktionen die eben die ganze HTML letzendlich erstellen

        

        

    }

    

    $objHTML = new HTML("testprojekt");

    $objHTML->setCSSRef("stylesheet.css");

    

    $objHTML->openHTML();

    $objHTML->createHead();

    $objHTML->createBody();

    $objHTML->createLogin();

    #usw..

    $objHTML->closeHTML();

    

?>

Beispiel 2, OOP 'light' (-> Alle o.g. Klassen werden nicht in eine Gott-Klasse verschoben sondern werden in der index.php instanziert und in einem Mix aus prozedualem Code und Objekten genutzt):

PHP-Code:


<?php

    $objHead = new HeadClass():

    $objTitle = new TitleClass("testprojekt");

    $objDB = new PDO(".., .., ..");

?>

<html>

<!--diverse andere Dinge in HTML-->

<?php

$objHead->create();

#usw.

?>

</html>

Beispiel 3, OOP + prozedualer Code:
(höchstwahrscheinlich entfällt diese Methode. Ich will es dennoch mal in das Rennen schicken)

PHP-Code:


<?php

    $debug_mode = 1;

?>

<html>

</head>

<?php

    if($debug_mode == 1)

    {

        ini_set('display_errors', 'On');

    }else{

        ini_set('display_errors', 'Off');

    }

?>

<title>testprojekt</title>

<link rel="stylesheet" href="stylesheet.css">

</head>

<?php

    #Mach irgendwas

    #Mach nochwas, aber die DB wird hierzu benötigt->erstelle ein PDO-Objekt

    $objDB = new PDO (".., .., ..");

    #usw.

    #prozedualer Code...

    #jetzt wird irgendwas per eMail verschickt:

    $objEmail = new Sendmail("server", "port", "usw");

    $objEmail->send();

    #usw.

    

?>

Ich hoffe damit verständlich gemacht zu haben was ich wissen will.
Wie macht ihr das? Reine OOP ohne Kompromisse wie in Beispiel 1?
OOP zweckmäßig und sinnig verwenden wie in Beispiel 2?
OOP verwenden punktuell und nur da wo es zweckmäßig erscheint wie in Beispiel 3? Beispiel 3 ist wahrscheinlich zu ignorieren, ich wollte es nur aufzeigen um beide extremen in den Topf hier geworfen zu haben).

**mermshaus** · 28.03.2017, 14:05

Das ist alles nicht so leicht zu beantworten.

„OOP“ und „prozedural“ umfasst mehr als Syntax und ist nicht immer so ganz trennscharf. Damit geht es schon los. Man kann zwar sagen, dass es OOP ist, sobald Funktionalität rein syntaktisch in Klassen und Methoden abgelegt ist. Das ist sicherlich nicht in dem Sinne falsch. Es lässt sich aber auch mit Objekten in einem Stil programmieren, der ziemlich dem entspricht, was gemeinhin mit „prozedural“ gemeint ist. (Der Code am Ende von deinem Beispiel 1 geht vielleicht ein wenig in die Richtung.) Auch umgekehrt ist es sicherlich möglich, auch ohne Klassen Code zu schreiben, der von der Denkweise Richtung OOP geht. (Ein Beispiel dafür sind die „prozeduralen“ mysqli-Funktionen, die als ersten Parameter immer die Instanz erwarten, mit der sie arbeiten. Das bietet sich in eigenem Code aber jetzt nicht unbedingt an, weil viele Hilfestellungen fehlen, die in Klassen enthalten sind. Zum Beispiel Sichtbarkeiten.)

Es gibt keine Patentantwort, wie man das, was du beschreibst und nachfragst, „richtig“ macht. Dazu sind zum Beispiel die denkbaren Anforderungen zu vielfältig. Verdeutlichung dazu: Wie hebt man ein Loch aus? Wenn es darum geht, einen Busch zu pflanzen, ist ein Spaten das richtige Werkzeug. Wenn es um ein Fundament für ein Hochhaus geht, braucht es ungleich komplizierteres Gerät. Zudem gilt es viel mehr zu beachten, und es kommen wahrscheinlich etliche Anforderungen hinzu, die nur noch sehr begrenzt mit dem tatsächlichen Vorgang des Grabens zu tun haben.

Ich habe im Laufe der Jahre so einige Versuche gelesen (und auch selbst zu verfassen versucht), den Aufbau eines einfachen OOP-basierten Systems zu erklären. Es ist sehr schwierig, irgendwo sinnvoll einen Cut zu machen, wo man mit der Abstraktion und Komplexität aufhört und was man noch mit reinnimmt und was nicht mehr. Man kommt zwangsläufig vom Hundertsten ins Tausendste. Mein Tipp ist deshalb bei so was immer, mal einen Blick in Demoprojekte oder Tutorials von bestehenden Frameworks und CMS und Template-Engines zu werfen, um ein Gefühl für die Sache zu bekommen. Die haben sich alle sehr intensiv mit genau den Fragen befasst, die du auch gerade hast, auch wenn man das auf den ersten Blick nicht gleich vermutet. Unvollständige Liste der üblichen Verdächtigen: Silex, Laravel, Symfony, Twig, WordPress, … Das ist ganz bestimmt gut investierte Zeit und wird eine Menge Dinge klären.

Noch subjektiver zu einigen Abschnitten deiner Beiträge:

Lagere ich wirklich alles in Funktionen/Methoden der Klasse aus und rufe dann lediglich die Methoden auf die mir dann HTML-Abschnitte generieren?
Wirklich alles oder doch wieder eine Kombination aus konventioneller Programmierung in der index.php + Klassen?

Ich habe darüber gerade noch mal einige Zeit nachgedacht, aber das ist letztlich einfach vom Projekt abhängig und von dir als Entwickler und deinen Erfahrungen und dem, was du machst oder machen willst.

Zur Positionierung von HTML: Es wird in dem Bereich oft mit etwas gearbeitet, das sich so grob „View-Script“ nennt oder „Template“. Das sind Dateien mit HTML-Fragmenten (in der Regel keine kompletten Seiten), die PHP-Code enthalten, der nur Ausgabelogik durchführt (einfache Schleifen und Bedingungen), keine Geschäftslogik. Die werden oft mit der Endung *.phtml abgelegt, um sie von normalen PHP-Dateien mit (in der Regel) einer Klasse pro Datei zu unterscheiden. Bei Nutzung von einer Template Engine ersetzt deren Syntax den PHP-Code in diesen Dateien, aber mit PHP geht es auch. Diese Templates werden dann in einer PHP-Klasse eingebunden (heißen in der Regel was mit „View“), der auch die darzustellenden Daten gesetzt werden, auf die dann in der Template-Datei zugegriffen werden kann.

Hier wird es etwas weiter erklärt:

- https://www.smashingmagazine.com/201...hp-templating/

Diese Templates sind untereinander oft über mehrere Ebenen geschachtelt. Es gibt in der Regel eines oder mehrere Rahmen-Templates (Layouts genannt), die den HTML-Körper (html, head, body, …) enthalten und Platzhalter für die Ausgabe anderer Templates, die dann Haupt-Content, Seitennavigation und dergleichen enthalten. Die können dann in sich auch wiederum noch mal weitere Templates einbinden usw. Dazu meist noch einige Hilfs-Templates (so eine Art „Helfer-Funktionen“), die Bausteine enthalten, die man an verschiedenen Stellen benötigt. Etwa den Rahmen für eine Box oder ein Template, das Eingabedaten in einer einfachen Tabelle darstellt. (Das sind oft Decorators.)

Das war jetzt leider keine tolle Erklärung, weil sofort wieder das oben beschriebene Problem auftaucht, dass kaum ein Ende zu finden ist und dass es schwierig ist, Teilaspekte wie diese Variante des Templatings losgelöst zu betrachten.

Das wird dir aber sicherlich alles schnell wieder begegnen, wenn du dich ein wenig in bestehende Frameworks oder dergleichen einarbeitest.

Will ich z.B. im Body der HTML-Seite eine Navigationsleiste machen, rufe ich an entsprechender Stelle die Methode 'createNaviBar()' der Klasse 'Header' auf (Header wäre dann die Klasse die sich um den Kopfbereich der Seite widmet bzw. diese erstellt und die Methode 'CreateNaviBar' generiert mir dann die Navigationsleiste).

Das kann man so in der Art machen, auch wenn das spontan eher kleinteilig wirkt. Spezialisierte View-Klassen ergeben Sinn, es tut aber oft auch eine Instanz einer generischen View-Klasse, der man als HTML-Template dann die „PHTML“-Datei setzt, die zum Beispiel die Navigationsleiste enthält. Die Instanz könnte man als Parameter der übergeordneten View zuweisen, die ihrerseits das HTML für das Rahmen-Layout enthält.

Ganz grob:

PHP-Code:


$layout = new View('scripts/layout.phtml');
$header = new View('scripts/header.phtml');

$layout->set('headerContent', $header);
echo $layout->render();

Und in layout.phtml könnte dann zum Beispiel stehen:

Code:

<!doctype html>
<html>
<head>
  ...
</head>
<body>
  <?=$this->get('headerContent')->render()?>

  ...
</body>
</html>

Das jetzt aber wirklich nur ganz schematisch als Pseudocode.

Wie unterteile ich die Klassen dann am besten? Habe ich eine 'gottgleiche' Klasse welche dann jeweils Methoden für die einzelnen Bereiche bereithält?

Gott-Klassen sind nie gut. Mit einer zu feinen Verästelung und Unterteilung wird es aber auch mühselig. Hängt von den Anforderungen des Projekts ab. Ich mache es gern erst mal nicht zu komplex und warte erst mal ab, wo sich Redundanzen ergeben (weil ich an verschiedenen Stellen ähnliche Design-Elemente/Widgets haben will) oder wo ein Template zu komplex wird, und unterteile dann weiter.

(Habe keine Zeit mehr. Vielleicht nachher noch mehr.)

**Master0Blicker** · 28.03.2017, 17:37

@mermshaus

Wow, vielen Dank! Genau so etwas wollte ich wissen.
Und wenn noch mehr folgen sollte, dann nochmals danke schön und noch ein größeres Wow!

BTW:
Ich habe noch nie von diesen phtml-gehört oder gelesen. Ein View sagt mir auch gar nichts im Zusammenhang mit PHP.
Den Link werde ich mir heute Abend mal durchlesen und schauen ob das was für mich wäre.

**SysOp** · 29.03.2017, 09:19

Super schöne Erklärung!

Ohne den Text kürzen zu wollen, es sind für mich 2 wesentliche Schlüsselsätze enthalten.

Es lässt sich aber auch mit Objekten in einem Stil programmieren, der ziemlich dem entspricht, was gemeinhin mit „prozedural“ gemeint ist.
....
Auch umgekehrt ist es sicherlich möglich, auch ohne Klassen Code zu schreiben, der von der Denkweise Richtung OOP geht

Ich stelle immer wieder fest, dass aus OOP eine Art heilige Kuh gemacht wird, ist etwas in OOP programmiert, wird es per se als gut angesehen. Umgekehrt ist prozedualer Code immer böse. Ähnliches liest man bei der Verwendung von mail() und es gibt noch ein paar andere Punkte, denen man Verallgemeinerungen angedeihen lässt, die irgend wie zu Gesetzen erhoben wurden.

In Wirklichkeit hängt die Wahl des Stils auch von solchen Dingen ab, wie z.B. "wie viele Leute arbeiten an einem Projekt", oder "wie modular muss das ganze sein". Oft würde es reichen, wiederkehrende Aufgaben (z.B. deine Navigationsleiste) einfach in Funktionen auszulagern und der Code hätte alles, was er braucht auch ohne OOP.

Anders gesagt:
Unterstelle ich den Entwicklern von PHP ein gewisses Mass an Voraussicht, könnte man sich auch fragen, wieso sie prozedualen Code überhaupt unterstützen und OOP nicht zwangsweise vorschreiben. Ich denke, dass sie die Notwendigkeit erkennen, dass jeder Stil durchaus seine Berechtigung hat und es manchmal einfach vernünftiger ist, etwas prozedual zu programmieren, als es immer in eine Klasse zu zwängen.

Die Debatte OOP gegen "strukturierten Code" ist schon so alt, dass ich sie schon aus meine Anfangstagen kenne und das ist mittlerweile schon recht lange her.
Ich habe nie an wirklich grossen Projekten mit gearbeitet und bin in all den Jahren fast immer ohne OOP ausgekommen. Unstrukturiert würde ich meinen Code aber dennoch nicht nennen.

Aber was weiss ich schon, ich nutze ja auch mail()

**Master0Blicker** · 29.03.2017, 09:30

Ich weiß nicht ob ich hier fragen oder einen neuen Thread öffnen soll?#

Ich habe Fragen zu diesem Template-Ding namens 'Twig'.
Als ich den o.g. Link gefolgt bin und mir die Beschreibung dieser Template-Methode für das Trennen von PHP (Funktionalität) und HTML (Design) durchgelesen habe, war ich begeistert.
Nach der Installation von Twig (ist eigentlich nur in das Root-Verzeichnis ablegen), Implementierung in das Projekt und erstem (begiestertem) ausprobieren, ist mir aufgefallen das ich doch auf Probleme laufe.

Ich habe eine Root-HTML-Seite in der ich verschiedene Module (DIV-Container mit entsprechendem Content -> abhängig vom zu zeigenden Inhalt / Userinput) einbinde. Rein in PHP würde ich der 'Steuerungslogik' folgend, an entsprechenden Stellen die entsprechenden Objekte/Methoden ausführen.

In Twig (und wahrscheinlich in allen Template-Engines oder wie man diese auch nennt), kann ich Platzhalter im Root-Dokument (Parent) bestimmen, Dann ein Child-Element in Twig aufrufen mit HTML-Code für diesen Platzhalter und dort bestimmen welcher Parent Voraussetzung ist damit dieser dann automatisch geladen wird.

So, jetzt die Krux an der Geschichte:
Wie mache ich es wenn ich im Root-Dokument viele Platzhalter haben will und diese dynamisch einbinden möchte (der Steuerungslogik folgend)?
Das geht doch schon rein logisch gar nicht, oder habe ich da irgendwas falsch verstanden? Die TWIG-Doku ist ziemlich schwammig und es gibt diese nur in englisch. Ist für mich zwar normalerweise kein Problem, dennoch in Kombination mit schwammiger Beschreibung wird es schon schwer..

Daher meine Frage:
kenn sich hier jemand gut mit Twig aus und kann mir erklären ob ich ein Denkfehler diesbezüglich habe oder ob das damit gar nicht möglich ist zu realisieren daß man mit Templates + vielen Platzhaltern ein dynamisch veränderbares HTML-Dokument im LEGO-Bausteineprinzip umsetzen kann?

Oder habe ich da grundlegend eine falsche Vorstellung vom ganzen?
Wenn ich ein HTML durch PHP generiere, dann entscheide ich ja Bereich für Bereich was reingeschrieben wird, richtig?

Nehmen wir mal den Login->Bereich der oftmals oben rechts in der Head-Navibar untergebracht ist und links davon oftmals eine Navigation durch Themen der Seite betreffend.

Loginbereich / Div-Container:
Nicht Eingeloggt -> zeige im Login-Div das Loginformular an.
Eingeloggt -> zeige Username, Last-Login-Datum/Uhrzeit und den Logout-Knopf.

Navibar:
Ist nichts ausgewählt, gibt es kein 'Subnavigation' darunter. Div-Bereich für Subnavigation -> leer.
Ist im Haupt-Navigationsbereich ein Thema sugewählt, beinhaltet der darunterliegende subnavi-Bereich Unterthemen zum auswählen. Usw..

Alleine hier habe ich ja schon mehrere Platzhalter die dynamisch befüllt werden sollen. Dabei sind wir ja erst im Head-Title-Bereich...

Also kurz und bündig:
Kennt sich jemand mit Twig o.ä. aus? Und wie wird da ein dynamischer Seitenaufbau realisiert? Geht das überhaupt?

Ich hoffe auf eure Hilfe und bedanke mich schon einmal im Voraus!

**Master0Blicker** · 29.03.2017, 09:39

@SysOp

Beruhigend zu wissen das man nicht auf Biegen und Brechen in OOP gezwängt werden muss.

Ich programmiere seit kurzer Zeit auch in Python. In einem sehr guten deutshen Forum bin ich intensiv unterwegs und habe schon einige male gehört -> ist nicht OOP, warum machst du das so und nicht 'richtig' (also OOP).

Um wieder in PHP ein wenig up-to-date zu sein, wollte ich eben wissen wie das hier so gesehen wird damit ich nicht im Start schon auf das falsche Pferd gesetzt habe.

Auch um dem vorzubeugen hier belächelt und belehrt zu werden wenn ich Codefragmente poste die klar nicht OOP sind wie in dem anderen Forum geschehen. Ist zwar nicht schlimm wenn das passiert, aber ich wäre schon gerne auf dem 'richtigen' Weg. Deiner Aussage und dem des anderen Users folgend gibt es viele richtige Wege und daher bin ich beruhigt.

Danke

**h3ll** · 29.03.2017, 09:58

Die Sache ist, wenn man einmal mal mit OOP angefangen hat, will man nicht mehr zurück.

Das ist ungefähr so wie Raucher, die jetzt Nichtraucher geworden sind. Die Nichtraucher wundern sich, warum die Raucher immer noch rauchen. Ohne Zigaretten ist das Leben doch so viel besser. Und die Raucher denken sich über die Nichtraucher: Lass mich doch in Ruhe, mein Opa hat auch geraucht und ist 90 Jahre alt geworden!

**SysOp** · 29.03.2017, 14:12

Sorry, aber den Vergleich halte ich für misslungen, es spricht eigentlich nichts FÜR das Rauchen aber alles spricht dagegen!

Nüchtern betrachtet gibt es aber durchaus auch Argumente, die gegen OOP sprechen (z.B. Ressourcen-Bedarf, Geschwindigkeit).

Ich argumentiere hier auch nicht pro prozedzual und contra OOP (ich kann übrigens beides), stelle nur für mich persönlich fest, dass ich bisher auch sehr oft ohne ausgekommen bin ohne in meinen Augen nennenswerte Einbussen an Vorteilen verzeichnen zu müssen.
In vielen Fällen macht es auch kaum einen Unterschied, ob man nun public function bla () in einer Klasse anpasst oder eine function bla () in einer functions.php.

**Master0Blicker** · 29.03.2017, 16:40

OOP ist kein Muss, ist aber meistens zu bevorzugen. Das war mir schon klar im Großen und Ganzen.
Die Frage ist aber: wie weit treibt ihr das im Allgemeinen?
Bestehen eure Projekte 'nur' aus Klassen welche die Darstellung komplett generieren (ich gehe mal davon aus das dies aus DIV-Containern + Inhalt besteht) oder habt ihr zwischen den prozedualen Code-Schnipsel dann Objekte die z.B. Mails versenden, die DB-Verbindung managen und der Gleichen?

Erstellt ihr eine Klasse für den Body in HTML? Für jegliche DIV-Container eine Klasse usw.? Oder macht ihr 'einfach mal' und an Stellen, wo es Sinn macht, macht ihr dann eine Klasse?

Zu Twig nochmals:
Hat hier jemand damit Erfahrung? Wenn nein: gibt es ein Forum wo ich TWIG-User finde zum mit Fragen löchern? Ich würde gerne wissen wollen wie das mit dem 'inherit' auf viele Child-Elemente geht, wenn es überhaupt geht?

**h3ll** · 29.03.2017, 16:49

Zitat von SysOp Beitrag anzeigen

es spricht eigentlich nichts FÜR das Rauchen

Da ist ein Raucher wohl anderer Ansicht.

Zitat von SysOp Beitrag anzeigen

Nüchtern betrachtet gibt es aber durchaus auch Argumente, die gegen OOP sprechen (z.B. Ressourcen-Bedarf, Geschwindigkeit).

Wenn Ressourcen und Geschwindigkeit ein Thema werden, nimmt man in der Regel sowieso kein PHP.

Und dass OOP langsam ist, stimmt vielleicht auch nur auf dem ersten Blick. Denn OOP betrifft ja nur den Programmcode. Was der Compiler daraus macht, ist wieder eine andere Sache. OOP-Code kann sogar schneller sein als prozeduraler Code.

Eine Automatikschaltung in einem Auto wird auch als langsam angesehen und eine manuelle Schaltung als schnell. Aber es gibt auch Automatikgetriebe, gegen die hat ein Handschalter nicht den Hauch einer Chance. Also was zählt ist nicht was davor ist, sondern was dahinter raus kommt.

Zitat von SysOp Beitrag anzeigen

Ich argumentiere hier auch nicht pro prozedzual und contra OOP (ich kann übrigens beides), stelle nur für mich persönlich fest, dass ich bisher auch sehr oft ohne ausgekommen bin ohne in meinen Augen nennenswerte Einbussen an Vorteilen verzeichnen zu müssen. In vielen Fällen macht es auch kaum einen Unterschied, ob man nun public function bla () in einer Klasse anpasst oder eine function bla () in einer functions.php.

Tja, aber spätestens dann, wenn man eine function bla() aufruft, die in OOP eine private function bla() wäre, da machts dann einen Unterschied.

**Quetschi** · 29.03.2017, 21:49

Rein prozedural schreib ich meist etwas, was nur einmalig läuft und nicht viel mehr als 50 Zeilen Code benötigt. Selbst bei solchen "Wegwerf-Scripten" kommt aber doch schnell der Punkt, ab dem es gewisse Vorteile mit sich bringt das in eine Klasse mit 2-3 Methoden zu packen auch wenn das dann lediglich Pseudo-Klassen sind die mit OOP nicht wirklich was zu tun haben. Es vereinfacht vieles und man behält in der Regel dadurch auch einen besseren Überblick.

Bei allem was darüber hinausgeht ist es in der Regel schon sinnvoll Objektorientiert zu arbeiten - dann sollte man sich jedoch zumindest mit den gängigsten Praktiken auseinandersetzen sonst kommt dabei nur irgendwelches Zeug raus, dass sich nicht wirklich gut nutzen lässt -> z.B. sowas https://de.wikipedia.org/wiki/Gottobjekt

**mermshaus** · 30.03.2017, 10:54

@SysOp:

Ich stelle immer wieder fest, dass aus OOP eine Art heilige Kuh gemacht wird, ist etwas in OOP programmiert, wird es per se als gut angesehen. Umgekehrt ist prozedualer Code immer böse. Ähnliches liest man bei der Verwendung von mail() und es gibt noch ein paar andere Punkte, denen man Verallgemeinerungen angedeihen lässt, die irgend wie zu Gesetzen erhoben wurden.

In Wirklichkeit hängt die Wahl des Stils auch von solchen Dingen ab, wie z.B. "wie viele Leute arbeiten an einem Projekt", oder "wie modular muss das ganze sein". Oft würde es reichen, wiederkehrende Aufgaben (z.B. deine Navigationsleiste) einfach in Funktionen auszulagern und der Code hätte alles, was er braucht auch ohne OOP.

Prinzipielle Zustimmung, dass OOP nicht immer die notwendigerweise „beste“ Option ist. Wobei ich da mit Qualifizierungen letztlich vorsichtig sein möchte, weil etwa ein Konzept nicht per se „schlecht“ oder „schlechter“ sein muss, nur weil es für einen Anwendungsfall vielleicht nicht optimal ist. Das (nicht auf dich bezogen) geht so in Richtung eines Pauschaldenkens, das meines Erachtens nichts bringt.

Bei mail() kann ich aber aus Erfahrung sagen, dass man bei jedem Problem mit E-Mail-Versand sehr gut beraten ist, erst mal die bestehende Lösung durch eine aktuelle Mailerklasse zu ersetzen, bevor man weiter darüber nachdenkt.

Ich habe erst kürzlich was in der Richtung gemacht. Da landeten Mails mit „Postkartenbild“-Inhalten im Spam-Ordner. Der Versende-Code nutzte sogar eine (etwas dünne) Wrapper-Klasse um mail(), die auf mich ganz okay wirkte, aber 10 Jahre alt war. Da der Versand von Bildgrüßen ohne großartigen Text nicht gerade optimal ist, um *nicht* als Spam klassifiziert zu werden, hatte ich befürchtet, dass das nicht so einfach werden würde, die Geschichte zu retten. Ich habe es erst mal nur auf den PHPMailer umgestellt (was schon etwas Gebastel war, weil ich das Bild-Embedding (cid) für HTML-Mails umstricken musste) und gesagt, sie sollen es mal mit den Problemfällen testen. – Das hat tatsächlich schon gereicht. Das mit den Mailerklassen ist keine urban legend, die bloß jeder nachplappert.

Anders gesagt:
Unterstelle ich den Entwicklern von PHP ein gewisses Mass an Voraussicht, könnte man sich auch fragen, wieso sie prozedualen Code überhaupt unterstützen und OOP nicht zwangsweise vorschreiben. Ich denke, dass sie die Notwendigkeit erkennen, dass jeder Stil durchaus seine Berechtigung hat und es manchmal einfach vernünftiger ist, etwas prozedual zu programmieren, als es immer in eine Klasse zu zwängen.

Das dürfte auch damit zu tun haben, dass PHP letztlich doch sehr dicht an C dran ist. Viele PHP-Funktionen sind 1:1-Mappings zu C-Libs. Das ist kein Widerspruch zu deiner Aussage. Das ist aber glaube ich ein recht weitschweifiges Thema. Ich würde da wie gesagt einfach nicht versuchen, künstlich zu fundamentale Gegensätze zwischen den Paradigmen formulieren zu wollen. OOP ist auch nicht vom Himmel gefallen und hat bei Null gestartet und Programmierung neu erfunden. Das ist alles eher eine kontinuierliche Entwicklung, die immer auf dem aufgebaut hat, was schon da war. Dafür finden sich auch rasch Indizien, wenn man ein wenig darüber nachdenkt. Methoden in PHP heißen „function“, JavaScript hat kein syntaktisches „class“-Konstrukt, in Python ist – gefährliches Halbwissen – der erste Parameter einer Methode die Instanz (vergleiche etwa in PHP die mysqli-Funktionssammlung). C selbst kennt meines Wissens auch keine Klassen. Und letztlich müssen alle abstrakten Konzepte auch wieder in Bytecode und Assembler überführt werden, damit die CPU damit was anfangen kann.

Letztlich ist das alles in gewisser Weise immer eine Suppe. Es sind alles nur syntaktische Abstraktionen, die es uns Menschen erleichtern sollen, Code zu schreiben, den wir besser nachvollziehen können (den wir überhaupt noch in endlicher Zeit verstehen können) und bei dem uns die Technik vor offensichtlichen Fehlern bewahren soll. Beispiel Sichtbarkeiten: Wenn was private ist, kann ich darauf nun mal nicht versehentlich zugreifen. Das kontrolliere aber nicht ich als Entwickler, das macht der Compiler für mich. Er nimmt mir Arbeit an, indem er auf Basis von Konventionen und bestimmten Regeln offensichtliche Fehler ausschließt. So habe ich als Entwickler mehr freie kognitive Kapazität, um die Komplexität der Gesamtanwendung besser verstehen zu können. Und je komplexer meine Anwendung ist, desto mehr brauche ich diese Hilfestellungen und desto mehr profitiere ich davon. Grob gesagt.

Das ist weder gut noch schlecht. Das ist einfach bloß eine Sache.

PS: Um den Blickwinkel noch zu erwähnen: Wenn ich fremden Code lese, ist es oft schwierig, den zu verstehen, weil Programmierung nun mal per se nicht so die simpelste Tätigkeit ist, die man ausüben kann. Deshalb bin ich für jede Sache dankbar, die mir das Verständnis erleichtert. Und Klassen mit Syntaxkonstrukten wie Sichtbarkeiten sind ein Vokabular, das dabei hilft, weil ein „private“ im Fremdcode die gleiche definierte Bedeutung hat wie in meinem eigenen Code. Je mehr Konventionen man befolgt, desto klarer und unmissverständlicher werden die Dinge – wenn alle Beteiligten die Konventionen kennen. Das ist bei syntaktischen Konventionen aber in der Regel der Fall. Bzw. setzt der Compiler (oder auch erst der Interpreter – je nach Sprache) ein gleichartiges Verständnis durch. – Wobei auch das im Umkehrschluss nicht ausschließen kann, dass es auch schlecht geschriebene Klassen gibt. Es reicht nicht, dass das „private“ da ist, es muss letztlich doch auch noch korrekt eingesetzt werden.

**mermshaus** · 30.03.2017, 12:14

@Master0Blicker:

Der Frage zu Twig kann ich leider nicht wirklich folgen. Ein Codebeispiel würde vielleicht helfen.

**Master0Blicker** · 30.03.2017, 13:37

@mermhaus

Vorlage 'Main-HTML' (main.phtml):

HTML-Code:

<html>
    <head>
        <title>Mein Projekt</title>
    </head>
    <body>
    <div id="content1">{% block content1 %}{% endblock %}</div>
    </body>
</html>

Dann habe ich einige content.phtml (content[n].phtml)-Templates.

Diese content-datei (content1.phtml): wird u.a. so erstellt:

HTML-Code:

{% extends "main.phtml" %}
{% block content1 %}
<div>
<!--Hier halt der Inhalt der ich haben will wie z.B. für den Login-Bereich-->
</div>
{% endblock %}

Wenn ich nun die main.phtml laden will mit der content1.phtml welche für den Block-Bereich 'content' ersetzt werden soll, dann muss ich ja folgendes machen:

PHP-Code:


$template = $twig->loadTemplate('content1.phtml');

Beachte: ich muss hier das einzufügende Template laden. Dieses ladet wahrscheinlich automatisch das main.phtml-Template weil dort das 'extends' auf diese main.phtml verweist (/votraussetzt ?).
So habe ich das ausprobiert und es funktioniert auch wunderbar.
ABER: was mache ich wenn ich weitere Templates in das Main-Template einfügen möchte? Natürlich in andere Block-Bereiche, nicht das wir uns da falsch verstehen...

Also hier nochmals mein main.phtml:

HTML-Code:

<html>
    <head>
        <title>Mein Projekt</title>
    </head>
    <body>
    <div id="content1">{% block content1 %}{% endblock %}</div>
    <div id="content2">{% block content2 %}{% endblock %}</div>
    <div id="content3">{% block content3 %}{% endblock %}</div>
    </body>
</html>

Und jetzt habe ich content1.phtml, content2.phtml, content3.phtml usw..
Wie kann ich dann in PHP TWIG anweisen das main-Template mit allen Sub-Templates zu laden? Mit einem geht es wie ich es beschrieben habe, aber mehr als eins verstehe ich nicht?

Verständnigsfrage zu OOP in PHP