PHP Objekte Performance

[Moni86]

Guten Morgen,
ich versuche mich gerade in die OOP einzuarbeiten. Mir fehlt natürlich etwas die Praxis und da viele Tutorials die Frage nicht wirklich beantworten, kann vielleicht hier mir einer helfen? Das wäre super.

Mir fehlt etwas das Verständnis mit den Umgang von Objekten und bezogen auf die Performance / Speicher. Oft liest man ein Singleton bei einer Datenbank-Verbindung zu nutzen um aus Performance Gründen nicht mehrer Datenbank Objekte zu haben, dann programmiert einer ein Fotoalbum wo der Verweis/Pfad, Name etc. aus der Datenbank geholt wird. Jedes Bild ist hier dann ein Objekt.

Ich versuche einmal ein MVC selber zu erstellen/nachzubauen um später für Frameworks ein besseres Verständnis zu kriegen. Genau hier tut sich bei mir die Frage auf, so wenig wie möglich an Objekten und viele Klassenkonstanten...Oder genau anders? Irgendwie handhabt das jeder anders und mir fehlt wie gesagt die Erfahrung.

Könnt Ihr mir hier weiterhelfen? Gibt's hier ne Faustregel die man mit auf den Weg geben kann?

Warum soll ein Framework performanter sein als der andere? Autoloading machen die meisten über Composer und Controller und Action Ansatz ist ähnlich. Ist hier vielleicht der Unterschied mit der Objekthandhabung?

Über etwas Lich im Dunklen würde ich mich sehr freuen.

Liebe Grüße
Moni

[hausl]

Oft liest man ein Singleton bei einer Datenbank-Verbindung zu nutzen um aus Performance Gründen nicht mehrer Datenbank Objekte zu haben

Singleton ist mittlerweile ein Antipattern, nicht nutzen. Schau dir "Depency Injection" an. Dh das eine Datenbankverbindungsobjekt wird in andere Objekte die es benötigen übergeben ("injiziert"). Da gibt es dann do Dinge ("DI-Container") wie Pimple oder PHP-DI die das ganze noch vereinfachen.

so wenig wie möglich an Objekten und viele Klassenkonstanten

Versteh ich nicht.. Man kann Objekte nicht mit Klassenkonstanten "vergleichen", das ist ja was ganz anderes.

Ev. ein allgemengehaltener Tipp: Mach dir über Performance in dieser Hinsicht nicht zu viele Gedanken. Schau das der Code sauber bzw. den "modernen Techniken" entprechend ist, dann fährst du sicher nicht schlecht.

[Moni86]

Bei den Konstanten kann ich ja die Funktion nutzen ohne eine Instanz zu erzeugen. DI habe ich schon gelesen. Schaue ich mir genauer an, vielen Dank. Und zum Gefühl her mit den Objekten, wie ist das mit der Performance - drauf achten das möglichst gering gehalten wird oder ist so ein Beispiel mit den Bildern kein Problem?

[hausl]

Bei den Konstanten kann ich ja die Funktion nutzen ohne eine Instanz zu erzeugen.

Du meinst static. Das ist zumeist auch ein Anti-Pattern, weil es gegen das Prinzip der OOP geht -> "OOP ohne Objekte?!"

[Moni86]

Macht Sinn was du sagst. Ich werde mich mehr zu DI informieren und reinarbeiten - es wird ein langes Wochenende Erstmal vielen Dank.

[Moni86]

Ich habe noch ein paar alte Bücher wo Anwendungen mit Singleton und Registry umgesetzt wurden. Die kann ich mir dann wohl sparen oder?

[hausl]

Gute Frage.. vermutlich(!) schon

In der Regel kannst du davon ausgehen, das alles was global verfügbar ist und die Scopes durchbricht "schlecht" ist. Dh global, static (Singelton), etc.. Im Grunde sollte immer alles sichtbare und saubere Schnittstellen haben wo die Objekte die Dinge die sie von außen benötigen übergeben bekommen, etwas damit machen und dann wieder was zurückgeben. Keine Magie!

wo Anwendungen mit Singleton und Registry umgesetzt wurden

Siehe zB http://stackoverflow.com/a/5166527

Globals are evil
This is true for the global keyword as well as everything else that reaches from a local scope to the global scope (statics, singletons, registries, constants). You do not want to use them. A function call should not have to rely on anything outside, ... .
...
All these Singletons and Registries you see in frameworks are code smells that should be removed in favor of Dependency Injection. Decouple your code.

Man sollte beispielsweise in einer Methode auch nie direkt auf $_POST oder so zugreifen, sondern selbst das als Parameter von aussen sauber übergeben. Damit schafft man dann keine verdenkten Abhängigkeiten und sieht immer sofort was "das Ding" benötigt.

Ging zwar jetzt nicht um Performance, aber das ist imho auch wichtiger ... Performance kam zB mit PHP 7 onboard mit

[Moni86]

Super, vielen lieben Dank hausl. Du hast mir sehr geholfen. Irgendwie wusste ich bei den ganzen unterschiedlichen Ansätzen/Authoren nicht mehr was "gut" und "böse" ist Du hast recht! Ich danke dir sehr. Ich werde berichten

[hausl]

Bitte, gerne.

[Ulfikado]

Singleton ist mittlerweile ein Antipattern,

MIt Verlaub aber das ist Blödsinn! Nur weil viele dafür gruslige Anwendungsgebiete ersinnen ist das Pattern noch lange nicht ein schlechtes!

[Ulfikado]

Du meinst static. Das ist zumeist auch ein Anti-Pattern, weil es gegen das Prinzip der OOP geht -> "OOP ohne Objekte?!"

Zunächst ist static kein Muster sondern ein Modifikator. Ansonsten ist Deine Aussage dazu, so pauschal unzulänglich/falsch. für static gibt es viele nette Anwendungsgebiete. Das "zumeist" macht Deine Aussage auch nicht besser! Static ist elementarer Bestandteil von OOP in den meisten Sprachen und das zu recht!

[rkr]

MIt Verlaub aber das ist Blödsinn! Nur weil viele dafür gruslige Anwendungsgebiete ersinnen ist das Pattern noch lange nicht ein schlechtes!

Singleton und Static haben wenig bis nichts mit OOP zu tun. Singleton ist einfach nur Procedural Programming in Disguise.

Sobald du irgendwo einen statischen Aufruf drin hast, verlässt du die OOP-Domäne und begibst dich runter auf die prozedurale Ebene. Das ist das gleiche, als würdest du Namespaces (statische Objekte), Prozeduren (statische Methoden / `funtion` in PHP) und $GLOBALS (public static $property) verwenden. Kann man alles machen, wenn man es für die eigene Lösung angemessen hält. Das ist aber kein OOP und es behindert das Wachstum einer Anwendung.

[Moni86]

Vielen Dank für eure Kommentare. Es gibt ja wie gesagt die Möglichkeit ohne eine Instanz auf static Attr. oder Methoden zuzugreifen. Mir fehlt wahrscheinlich noch die Situation wo ich das so hätte nutzen wollen aber genau hier kam mir die Frage auf. Wenn es für die Performance egal ist, dann kann ich doch auch einfach ein Objekt erzeugen. Oder wurde das gerade deswegen eingeführt, das man die Chance hat sich ein paar Objekte zu sparen und nur kurz die Methode nutzt? Dann macht es ja nur Sinn wenn es allgemein mit der Performance zusammenhängt. So war mein Gedanke zumindest.

Wie mit dem Singleton und der Datenbank oder lauter Objekte bei einer Bildergalerie mit tausenden von Bilder.

Auch wenn sich alle an eine moderne Konzepte halten, irgendwo muss es es doch Ansätze geben die gut bzw. schlecht sind. Wenn alle mit Composer autoloding, DI die Abhängigkeiten reduzieren ... Warum ist ein Framework "hungrieger" und das andere performanter laut manchen Aussagen?

Hier tut sich halt bei mir die Frage auf, auf was muss ich hier achten und was sollte ich vermeiden damit meine Anwendung auch bei vielen Nutzern gut läuft (außer einen starken Server).

Ich bin ja noch ganz am Anfang aber vielleicht habt ihr da ein paar gute Ratschläge bzw. Erfahrungen sammeln können.
Ich würde mich freuen
Vielen Dank

[hausl]

MIt Verlaub aber das ist Blödsinn! Nur weil viele dafür gruslige Anwendungsgebiete ersinnen ist das Pattern noch lange nicht ein schlechtes!

Ja ich war zu Allgemein, ich bezog mich zu der oft verwendeten Weise:

Oft liest man ein Singleton bei einer Datenbank-Verbindung zu nutzen

Zumindest kann ich mich an keinen konkreten Fall hier erinnern wo es empfohlen wurde.. was nicht heißt das es den nicht gibt, klar.

Diese Beschreibung trifft es konkreter:

Wegen der vielen Nachteile wird das Singleton-Muster (und auch das Idiom Double-checked Locking) mitunter schon als Anti-Pattern bewertet. Für Fälle, in denen tatsächlich technisch ein passender Bereich für ein Singleton existiert, können Singletons aber sinnvoll sein – insbesondere wenn sie sich auf andere „einmalige Strukturen“ wie zum Beispiel eine Abstract Factory beziehen. Trotzdem: Das korrekte Design von Singletons ist schwierig – in der Regel schwieriger als Designs ohne Singletons.

Quelle: https://de.wikipedia.org/wiki/Singleton_(Entwurfsmuster)

Zunächst ist static kein Muster sondern ein Modifikator.

Danke für die Richtigstellung des Ausdruckes.

Ansonsten ist Deine Aussage dazu, so pauschal unzulänglich/falsch. für static gibt es viele nette Anwendungsgebiete. Das "zumeist" macht Deine Aussage auch nicht besser! Static ist elementarer Bestandteil von OOP in den meisten Sprachen und das zu recht!

Hier geht es um PHP und das Thema von Moni86. Bezug war auf die breite Masse die hier im Forum immer wieder hochkommt ("Procedural Programming in Disguise") bzw. auch in dem obig verlinkten stackoverflow Beitrag erläutert ist. Hatte es nur nicht explizit erwähnt bzw. zu allgemein ausgedrückt, ok.

Siehe zB http://stackoverflow.com/a/5166527
Globals are evil
This is true for the global keyword as well as everything else that reaches from a local scope to the global scope (statics, singletons, registries, constants). You do not want to use them. A function call should not have to rely on anything outside, ... .
...
All these Singletons and Registries you see in frameworks are code smells that should be removed in favor of Dependency Injection. Decouple your code.

Jedenfalls danke für deine Anmerkungen.

[Ulfikado]

Singleton und Static haben wenig bis nichts mit OOP zu tun.

Dann erkläre mir mal bitte wie beide Sachen in rein Objektorientierten Sprachen wie Java oder C# zustandkommen!

Klar sind es OOP Elemente!

Sobald du irgendwo einen statischen Aufruf drin hast, verlässt du die OOP-Domäne und begibst dich runter auf die prozedurale Ebene.

Sorry aber das ist mir zu einseitig! Ich teile Deine Meinung hier in keiner Weise. Wenn static von Klassen (Methoden|Eigenschaften) verwendet wird ist es sehr wohl im Kontext der Klasse und nicht auf Funktionaler ebene.
OOP heist ja nicht ausschließlich im Kontext einer Instanz!