Das 🄿🅁🄾🄱🄻🄴🄼 mit den 🅂🄴🅃🅃🄴🅁 in PHP. Immutable Objects sind WICHTIG
ฝัง
- เผยแพร่เมื่อ 24 ก.ย. 2024
- Setter führen dazu dass diese auch benutzt werden, und auch dann wenn man es nicht will. Die willkürliche Verwendung davon führt zu Sideeffects im Code oder sogar zu Bugs.
Kanalmitglied werden und exklusive Vorteile erhalten:
/ @vitalijmik
🌐 Sonstiges
***************************
Weitere Themenvorschläge und/oder Kooperationen in die Kommentare.
#php #immutable #setter
🤑 Affiliate
***************************
Mein Gear: www.amazon.de/... *
Lade mich auf ein Kaffee ein: www.paypal.me/...
* Hierbei handelt es sich um ein Affiliate-Link, es entstehen keine weiteren Kosten beim Einkauf eines Produkts über diesen Link, du unterstützt aber meinen Kanal direkt.
🕛 Zeitstempel
***************************
Ich mag diese Art von Videos. Was auch mal ein spannendes Thema wäre wär die Verarbeitung von Bildern. Glaub das ist besonders für Einsteiger ein komplexeres Thema.
Joa das könnte man machen, aber PHP ist nicht sonderlich performant wenn es diesbezüglich geht. Ich könnte ja nach einer guten alternative mal suchen.
@@VitalijMik ja gute Idee. ich glaub das klassische Szenario is ja das Hochladen eines Profilbildes... ma muss es hochladen und dabei möglichst nochmal zuschneiden, vlt. auch komprimieren usw. vlt. will man noch ein Wasserzeichen drüberlegen...
Womöglich is das Thema dank PHP Frameworks aber auch gar nicht mehr so arg relevant... das kann ich auch grad gar nicht mehr einschätzen.
Danke für das Video. Ich finde es eine sehr gute Idee, wie man mit Objekten in PHP umgehen sollte :)
Danke, es ist sogar im PSR-7 Message vorgeschrieben dass Request und Response immutable sind. Man kann im Request und Response dann den HTTP Status Code nicht überschreiben(also ungewollt bzw aus versehen)
www.php-fig.org/psr/psr-7/#12-http-headers
Ich glaube viele verstehen das Thema auch einfach falsch. Setter sind ja nur eine Möglichkeit von mehreren, Daten eines Objekts zu verändern. Es geht ja vielmehr darum, Änderung am Objekt sichtbar zu machen und nicht darum, Änderungen an Objekten komplett zu vermeiden. Deswegen gibt es dann statt setter auch withXYZ() Methoden, bei denen man direkt sieht, dass ein neues Objekt zurückgegeben wird.
Den einzigen wirklichen Nachteil den ich bei der Thematik sehe ist der Overhead an Speicher, der dadurch entsteht. Bei jedem setzen von Daten außerhalb des Konstruktors muss das gesamte Objekt kopiert werden. Es gibt sicherlich einige Anwendungsfälle, bei denen man da an Grenzen stößt.
Ich meine der Garage collector von PHP löscht den clone sobald man aus einer Methode raus ist. Ich müsste das aber prüfen. Aber ja es geht wirklich darum um es zu zeigen dass man das Objekt verändert. Mir ist beim Schreiben des Textes diese Aussage nicht eingefallen
@@VitalijMik Ich weiß leider selbst nicht im Detail, wie sich der Garbage Collector von PHP im Vergleich zu dem anderer Sprachen wie C# verhält, aber demnach kann es durchaus zu Performanceproblemen kommen, sollte man zu viel Speicher auf einmal allozieren. Das wird aber eher die Seltenheit sein.
@@user-hw7pi2ld2r ich meine die Clones werden innerhalb einer Klasse erzeugt und sobald die Klasse nicht mehr in Benutzung ist, sind die Clones auch alle weg
@@user-hw7pi2ld2r Ich habe hier ein Script zum rumspielen vorberietet pastebin.com/Sy9LR6P0 die clones werden von PHP sauber aufgeräumt
aber in TYPO3 extensions bin ich gezwungen setter zu verwenden was soll ich tun
Ich habe ja gezeigt wie man immutable objects erstellt, mit einem Clone. Ich kenne mich nicht gut aus mit Typo3, zeig mir bitte ein Beispiel wo du die setter normalerweise verwendest und ich zeig dir dann was man da tun könnte
Hey Vitali, hat zwar nichts mit dem Video zu tun, aber wie wär's denn mal mit einem Template zu einem Aufbau einer Seite wie Wikiblödia. Also, so dass alle etwas hinzufügen können ? Das fänd ich mal ne Megasache ey :)
Es wäre zu groß um wiki komplett nach zu bauen. Und kleinere Variante wäre wenn man content hinterlegen kann und admins es freischalten können. Also im Grunde nur ein Formular der Daten in db speichert und man den content später sieht. Das ist wiederum zu einfach :D
Ah okay, du siehst hier PHP ausschließlich im Anwendungsfall Webseiten anzuzeigen?
Wir setzen PHP in unserem Projekt weitergehend ein, um z.b. Daten von anderen Servern abzurufen oder selbst als Datenquelle für andere Server zu dienen. Bei uns standen wir bisher einfach nie vor dem Problem das Setter ein Problem darstellen würden, geschweige denn das ein mehrfaches aufrufen eines Setters Effekte hätte die nicht gewollt sind. Aber unsere Setter sind auch nicht einfach nur Setter, sondern beinhalten schon etwas mehr Probrammlogik, um eben ggf. bei ungewollten Mehrfachaufrufen nicht irgendwelchen Mist zu veranstalten. Der klassische Setter bei uns kann nur dann einen Wert setzen wenn der Wert zuvor eben noch nicht gesetzt wurde. Ein erneutes aufrufen des Setter hat im einfachsten Fall gar keine Wirkung. Will man einen einmal gesetzten Wert ändern gibt es dafür dann andere Methoden. Klar könnte man das auch alles auf andere weise lösen, allerdings ist das Projekt über Jahre so gewachsen. Und wir versuchen hier schon nach Möglichkeit überall auf gleiche Verfahrensweisen im Code zu setzen. Eine Veränderung weg von der bisher verwendeten Methodik dürfte wohl ein größeres Refactoring nach sich ziehen, dafür fehlt aktuell einfach die Zeit bzw. das Personal.
Hi, nein nicht ausschließlich von Webseiten.
In Größeren Projekten möchte man doch immer wieder Teile anpassen ohne zu viel zu refactoren. Ich habe zum Beispiel ein import script der Fragt Daten aus der API und erzeugt daraus objekte um diese dann zb weiter zu reichen an die DB, zwischendurch gibt es Events wo das Objekt überall weitergereicht wird. Es gibt zb ja ORM das triggered intern events wie beforeSave oder onCommit etc und an all diesen Stellen kann man theoretisch das Objekt sich schnappen und einen setter aufrufen um daten zu verändern oder andere Werte anzuhängen.
Setter setzen die noch nicht gesetzt sind, sind auch ein nützliches Mechanismus, wobei ich das Persönlich zu hart finde. Ich frage mich dann bei sowas. Wieso könnte man den Wert nicht schon vorher ermitteln und diesen via Constructor setzen? Ist es notwendig überhaupt ein Setter später aufzurufen?
Ich habe ein Formular, wo der Anwender neue Daten eingeben darf. Wo werden die Daten dann bereinigt, wie Leerzeichen entfernt, kleine Buchstaben durch große Buchstaben ersetzt, oder bestimmte Stringformate in andere umgesetzt, wenn nicht im Setter? Das verstehe ich wiederum nicht. Ich habe es auch bisher nie anders gesehen 🤔
Ein Setter setzt den Wert mehr nicht, die komplette Prüfung findet bzw sollte immer vorher stattfinden in einem Validator oder ähnliches. Das heißt du hast die Werte schon vorher. Du kannst auch im Constructor deine Werte über die Private Methode editieren.
Was machst du aber wenn irgendjemand der mit dir zusammen an einem Code arbeitet und deinen Setter noch mal aufruft und deinen Wert überschreibt, irgendwo in irgend einer Methode und du wunderst dich dann wieso in die Datenbank was anderes reinkommt als erwarte.
Das Problem ist tatsächlich, dass sehr viele auch erfahrene Entwickler OOP nicht wirklich verstanden haben. Deshalb finde ich CLEAN Code und die SOLID Prinzipien so wichtig. Eine Methode sollte nur eine Aufgabe haben. Ein Setter sollte nur den Wert setzen. Nichts anderes. Validieren oder anpassen, sollte dann in einer anderen zum Beispiel privaten Methode stattfinden.
@@sven2529 da gibts viele Probleme.
1) Wird Programmierung anhand von Java und C# gelehrt, syntaktisch sehen die sich ähnlich zu PHP aber in PHP kann es sowas nicht passieren dass du ein Objekt jetzt erzeugst und 30 Minuten später muss davon ein Value gesetzt werden. in Desktop Anwendungen schon.
2) In den Schulen lehren nicht Programmierer sondern Lehrer, die haben ihr Wissen von anderen nicht Programmierern.
3) Clean Code und SOLID sind sehr dehnbare Begriffe. Du sprichst zwar hier von Single Responsibility aber das wird oft mit Single Action verwechselt. Ich kann durchaus kleinere Validierungen in einem Objekt in einer Privaten Methode ausführen. Wenn man es genauer betrachtet passiert das ja eh schon, zb das Casting von Datentypen, wenn alles aus der DB kommt ist es zunächst mal ein string. Wandelst du das alles in richtige Datentypen um? Nein das macht PHP für dich automatisch wenn du die Parameter richtig definiert hast.
SOLID sind Richtlinien und keine Gesetze ;)
@@VitalijMik Ich glaube langsam dich zu verstehen, was du mit deinem Video sagen willst. Aber jetzt um an deinem Beispiel zu bleiben... Wenn irgendjemand meint einen Wert überschreiben zu müssen, wird es auch schaffen. Notfalls wird er dann einen Setter in die Klasse schreiben. Ich verstehe es jetzt aber so, das es sich eher um ein Strukturelles Problem handelt und nicht um Setter. Wenn man irgendwo das Objekt verändern kann/will, obwohl das so nicht vorgesehen ist, ist schon was schief gelaufen.
Ich habe zum Beispiel ein Action, die wiederum Services aufruft die einer Domäne angehöhren. Jede Domäne hat eine klar formulierte Aufgabe und Objekte und kommt mit keiner anderen Domäne in Berührung. Wenn alle Ergebnisse in der Action ankommen, sind die längst verarbeitet und die muss man nicht mehr modifizieren. Aus Einfachheit verzichtet man auf weitere "Modifier" Klassen, den das spezielle kann auch im Setter gemacht werden. Das habe ich glaube ich aber auch aus C#
Ich muss mal darüber nachdenken und Beispiele kontruiren wo dein Fall eintreffen kann.
@@sven2529 Ich glaube schon das ich OOP verstanden habe. Aber hier geht es vielmehr um Frage, wie komplex muss ich meinen Code nun aufbauen. Ist komplexer Code gut, oder ist komplexer Code eben komplex, nur um irgendwelche "Richtlinien" zu befolgen. Ich für meinen Teil versuche so wenig wie Möglich komplexität in den Code einzubauen, oder ... soviel wie nötig. Der Code ist ja kein Feststoff, sondern eher wie "warme Knete". Wenn du mehr brauchst, kannst du mehr komplexität einbauen. Davor aber eher nicht, weil nicht jeder kann/wird das sofort verstehen.