Wo sind allgemein Static, Interface Klassen in MVC in ihrer Funktion Sinnvoll?

[mermshaus]

Ein, zwei Ergänzungen:

Aber warum hast du sie final gemacht? Was genau möchtest du damit erreichen oder verhindern?

um sie nicht veränderrn zu können. Ich verwende das in Comfig dateien.

Das ist ja offensichtlich, aber warum soll da keiner vas ändern können? Bist du dir sicher, dass es unter keinen Umständen passieren darf, dass jemand eine abgeleitete Klasse erstellt, Methoden überschreibt und dann eine solche Klasse übergibt?

Wenn sich ein Usecase ergibt, könnte man das final aber auch noch nachträglich entfernen. Es gibt schon gewisse Argumente dafür.

• http://ocramius.github.io/blog/when-to-declare-classes-final/ (via Extremely Defensive PHP)

Statische Dinge können aber auch erheblich von Nachteil für bestimmte Vorgehensweisen sein. [...] nicht von anderen Orten aus verändert werden.

deswegen final

Moment mal, final ist kein Synonym für readonly oder const.

Ich bin mir auch nicht sicher, ob die Wahl der Begrifflichkeiten vollständig Sinn ergibt. Hier noch eine Quelle, wieso static/global state besser vermieden werden sollte:

• http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/ (die komplette Reihe ist lesenswert (die „Flaw #1“-Überschriften usw. sind Links))

Ein Beispiel sind Funktionen zum de/serialisieren von Objekten. Speichern muss man die verschiedensten Dinge und dafür müssen ihre Daten in eine speicherbare Form gebracht werden und aus dieser wiederhergestellt werden können. Man erstellt sich dazu ein Interface ISerializable

gutes beispiel. Ich möchte Nachrichten Anzeige Programmieren im Programm. Lohnt es sich dafür *Interface zu verwenden oder *traits? Ich mein Die Funktionan die ich programmieren werden sind alle nach einem muster. Wozu dann noch Intefrace?

[…]

Ehrlich gesagt: Die Frage ist in der Form eigentlich nicht verständlich. „Nachrichten Anzeige“ könnte alles sein. Der Zusammenhang mit Interfaces und/oder Traits ist unklar.

Bei stark typisierten Systemen muss man einen Typ angeben. Wenn man keine Basisklasse hat, dann muss es eine andere gemeinsame Basis geben, die man da als Typ angeben kann, zum Beispiel ein Interface. Bei schwach typisierten Systemen, die auch nach dem Duck-Type-Prinzip arbeiten, kann man auch auf Interfaces verzichten. Ob man aber besser fährt, dass der Compiler und Entwicklungumgebung keine Ahnung davon hat, was wirklich zur Laufzeit abläuft und einem dann auch keine Unterstützung in der Entwurfsphase bieten können, steht auf einem anderen Blatt.

Allerdings. :) Anders gesagt: In der Regel zielt man in der PHP-Welt inzwischen auf eine möglichst strikte Typisierung ab (z. B. über explizite Typehints in Methoden-Signaturen), um robusteren Code zu schaffen und um etwa auch IDE-Features aus dem Bereich der statische Analyse nutzen zu können.