Was ist FINAL CLASS in PHP? Und WIESO sollte man es benutzen?

[@VitalijMik]

Final oder nicht final? was ist eure Meinung?

[@NeverCodeAlone]

Final auf jeden Fall

[@diafischchen]

super zusammengefasst. Hab in meinem Job gerade viel mit final Klassen zu tun von daher kommt das Video genau zur richtigen Zeit

[@VitalijMik]

dankeschön, es geht viel um Teamwork und Kommunikation;) rede also mit deinen Kollegen falls du mit der final Klasse arbeiten musst

[@Meinungsmacher]

Seher cool, ich hab bisher Final immer nur als Sicherheitsfeature genutzt um zu verhindern dass eine andere Software mit meiner Klasse blödsinn anstellen kann.

[@VitalijMik]

Vorsicht ist besser als Nachsicht :D

[@NeverCodeAlone]

...viele Wege fürn nach Rom ;)

[@pinkeHelga]

Ich bin kein Freund von zu restriktiver Softwarearchitektur. Eine einmal fertige Klasse sollte nicht mehr maßgeblich refaktorisiert werden. Egal ob Ableitung oder Nutzung der Methoden und Eigenschaften, eine Refaktorisierung kann immer Auswirkungen mit sich bringen. Wird etwas refaktorisiert, dann gibt es eine klare Trennung von Schnittstellenmethoden und internen Methoden. Die private-/protected-Schlüsselwörter bieten zusätzliche Möglichkeiten, die Vererbung zu steuern. Das Verhalten nach außen muß nach einer Refaktorisierung erhalten bleiben, oder man führt eine neue Klasse ein und erklärt die alte als deprecated. Für mich macht final nur Sinn bei Sprachen, die bei der Kompilierung zwischen früher und später Bindung unterscheiden und die späte Bindung Performanceeinbußen mit sich bringt.

[@VitalijMik]

Ich würde das nicht als restriktiv bezeichnen, es ist eher Schützend. Refactoring kommt immer wieder vor, nichts ist in Stein gemeißelt. Anforderungen verändern sich mit der Zeit. Refactoring bringt oft Auswirkungen mit sich, aber es ist einfacher ein Interface anzupassen und deren Implementierung als eine Klasse die abgeleitet wurde. Mit Interfaces definierst du Schnittstellen und mit final schützt du dich vor willkürlicher Ableitung. Ich würde es nicht als restriktiv bezeichnen sondern eher als Kontrollierbar, oder Steuerbar. Anarchie im Code ist echt schwierig.

[@pinkeHelga]

@@VitalijMik Das ist halt dieser Glaubenskrieg in der Programmierung. Für mich mach OOP nur Sinn wegen Vererbung, ansonsten hätte man bei Verbunddatentypen + Funktionen bleiben können. Die DOs und DONTs kamen im Nachhinein. Auch Refactoring will gelernt sein. Ich möchte nicht die Herausforderungen, die sich beim Refactoring stellen, in die Konzeption stecken. Damit sperre ich unnötig Möglichkeiten nur für den Fall, daß mal etwas geändert werden _könnte._ Interface brauche ich auch keine, wenn nicht der Fall eintritt, daß völlig unterschiedliche Klassen die selbe Schnittstelle benötigen. Eine gut durchdachte Vererbungshierarchie macht Interfaces in weiten Teilen unnötig. Ich würde Interfaces schon fast als Codesmell bezeichnen. In fast allen Fällen entsteht Copy'n'Paste Code mit minimalen Anpassungen. Bei gut organisierter Struktur könnte die Logik auch zentral in einer Funktion gesteuert werden. Maßvoll eingesetzt ist es eine Erleichterung bei der Entwicklung, aber in der Praxis sehe ich immer wieder exzessiven Overusage. Es macht vor allem dann Sinn, wenn eine definierte Schnittstelle gebraucht wird, die Implentierung aber völlig unterschiedlich ist, Betonung liegt auf völlig.

[@VitalijMik]

​@@pinkeHelga uff schwierige Aussagen, du sagst damit quasi das Gegenteil was die Mehrheit anderer Entwickler verfolgen. die SOLID Prinzipien sind dazu da um Testbaren Code zu schreiben, Copy und Paste entsteht eigentlich kaum, dann hast du falsche Implementierungen erstellt. Eine Struktur heißt dass du im Worst Case den kompletten Struktur Baum ändern musst, das ist der Nachteil einer Struktur. Ich denke es kommt darauf an welche Ziele man mit seinem Code verfolgt. Ich möchte Langlebige Software haben, die gut getestet ist wo fremde Entwickler ohne Probleme daran mitwirken können. Hatte mit Vererbung immer nur Probleme. Früher die MOdel Klassen zb eine kleine Vererbung und du schleppst eine komplette Datenbank Verbindung mit sich herum. Vererbung macht nur Sinn wenn man sich darüber gedanken gemacht hat und nur die Klassen für die Vererbung freigegeben hat, die dafür auch ausgelegt sind. Alle andere Klassen dürfen nicht vererbt werden.

[@pinkeHelga]

@@VitalijMik Ja, die Architekturphilosophie ist ein schwieriges Thema. Ich zwänge Projekte auch nicht gerne in ein enges Korsett an Prinzipien. Im Prinzip versucht man, Code vor unfähigen Entwicklern zu schützen. Ok, wenn ich mir so manchen Code ansehe, ist es vielleicht auch durchaus angebracht, anderen Entwicklern zu mißtrauen - was anderes ist es ja eigentlich nicht. Ich habe eher den Ansatz, das technisch Bestmögliche herauszuholen. Der Aufwand an Überlegungen, die dabei in die Architektur und Konzeption fließen, sind zugegebenermaßen nicht immer die wirtschaftlichsten. :) Aber für mich zählt das Resultat, bzw. die Art und Weise wie. Programmierung ist für mich nicht einfach nur ein Job oder ein Geschäft nach Wirtschaftlichkeit. Ich sehe mich da eher als Forscher / Wissenschaftler ohne die menschliche Komponente als Fehler im System. :) Ein Flugzeug würde ich auch nach bester Aerodynamik und Flugverhalten kontruieren, statt mit lauter unnötigem Gewicht, weil Teile in der Produktion so hilfreich sind - die müssen spätestens im Endprodukt entfernt sein.

[@pinkeHelga]

@@VitalijMik PS: Die Mehrheit der Entwickler verfolgt eingetrichterte Prinzipien, wie in den meisten Berufen. Schulmediziner haben auch ihre Daseinsberechtigung, haben aber auch oft nicht die Weitsicht über den Tellerrand hinaus. :)

[@zugdsbtngizudsgbnudsdsoiu]

Ich mag final nicht. Im Grunde verbietet man ja anderen seine Klasse zu erweitern was weit über den Verantwortungsbereich einer Klasse geht. Das fängt bei private and und endet mit final. Wenn man mal Magento Shops programmiert hat kennt man das Problem. Da wird einfach private verwendet weil mans gewohnt ist oder final weils besser sein soll, das hindert einen aber nur daran den Code an seine Anforderungen anzupassen. Es gibt bestimmt irgendwelche Sonderfälle in denen final notwendig ist aber meistens reicht es ja dann einfach nicht zu erben. Probleme bei Dependency updates werden ja meistens durch tests abgedeckt und kommen auch meist nur bei Majors zum Tragen.

[@VitalijMik]

Ja genau, man will ja mit final die willkürliche Ableitung vermeiden. Klassen die nicht als Final definiert sind, können abgeleitet werden und somit kann man es besser steuern. Auch beim Refactoring weiß man dann genau dass die final klasse nicht abgeleitet wurde und man hat mehr Freiheit. Ja durchs Testing wird vieles abgedeckt, da aber eh nicht jede Software zu 100% getestet ist, können Fehler passieren. In Shopware ist es zb auch so dass nicht nur durch Major Updates BC Breaks passieren sondern auch im Minor Releases. Es gibt neben der Ableitung auch andere Wege wie man einen Code an seine Anforderungen anpassen kann, diese habe ich zum Schluss im Video auch erwähnt. Ableitung sollte als alles letztes gewählt werden. Das wird zum Beispiel in neueren Programmiersprachen wie etwa Kotlin gelebt. Du kannst statt einer Ableitung die Klasse Dekorieren, auf Events hören, die Methode , die du anpassen willst, in einen eigenen Service auslagern oder Traits erstellen. Es gibt eigentlich fast immer ein Weg.

[@dermenschistweilesglaubtda41]

ich benutze immer final damit keiner mein code klauen kann

[@VitalijMik]

ja davor wird dich final nicht schützen ;)