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

[dedlfix]

Tach!

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?

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.

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?

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. Das Duck-Type-Prinzip kommt von: wenn es quakt wie eine Ente, wird es wohl eine Ente sein. Wenn man eine bestimmte Methode aufrufen kann, ist alles in Ordnung, Interfaces und Klassenzugehörigkeiten spielen dabei keine Rolle, Hauptsache das Ding hat die Methode. Da kann man auch einen Fuchs mit Fremdsprachenkenntnissen übergeben.

Interfaces legen nur fest, wie etwas an der Oberfläche aussehen muss. Da ist kein Code dahinter, der irgendwas macht. Den muss derjenige schreiben, der das Interface implementiert. Traits hingegen sind Codestücke, die man sozusagen anderen Klassen einverleiben kann. Ich hab noch nie Traits verwendet. Man kann gemeinsame Aufgaben auch als Service implementieren. Logging muss beispielsweise nicht in jede Klasse eingebaut werden, auch nicht als Trait. Da reicht es, die Logger-Instanz zu übergeben und wenn man was mitzuteilen hat, übergibt man den Text an eine Methode des Loggers.

Man könnte auch den Serializer als Service auslegen, aber dann kann der meist nur die von außen sichtbaren Eigenschaften ermitteln und nichts individuelles anstellen. Wenn man spezielle Dinge serialisieren muss, die nur die Klasse selbst kennt, dann braucht man den Serializer-Code an Bord. Aber da hilft auch kein Trait, denn der ist dann entweder so speziell, dass er gleich als direkter Code eingebunden werden kann, oder er ist wieder so allgemein, dass es ein Service auch tut (nebst einer Menge Graustufen zwischen diesen beiden Enden).

dedlfix.