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

[dedlfix]

Tach!

der Betreff sagt eigentlich alles. Ich hab Konfigurations-Dateien final gemacht und ziehmlich viel in diesem Bereich mit static gearbeitet.

Dateien - final? Final ist kein Begriff, der im Zusammenhang mit Dateien steht. Du meinst vielleicht Klassen. Aber warum hast du sie final gemacht? Was genau möchtest du damit erreichen oder verhindern?

• 1: Ist static in einer klasse sinvoll die nur einmal verwendet wird und das immer wieder? z.B. in den ganzen Controller klassen und Core Klassen in dem z.B. Router Klasse und App Klasse was die die Router Klasse aufruft.

Static hat nichts mit der Häufigkeit der Verwendung zu tun. Static nimmt man, wenn man keine Instanzen braucht/haben möchte/wasauchimmer, oder diese keinen Sinn ergeben, wie beispielsweise die Funktionssammlung in der Math-Klasse, die es oftmals in objektorientierten Systemen gibt. (In PHP nicht, das hat dafür ja eigenständige Funktionen). Statische Dinge können aber auch erheblich von Nachteil für bestimmte Vorgehensweisen sein. Zum einen muss man sich als Verwender darauf verlassen, dass sie richtig initialisiert sind und/oder nicht von anderen Orten aus verändert werden. Man holt sich mit statischen Dingen einen globalen Status ins Haus. Dinge wie automatische Testbarkeit sind damit nicht wirklich gut zu realisieren.

Wie immer, wnen du keine plausible Begründung für eine Vorgehensweise liefern kannst, mach es nicht so. Natürlich wirst du auch beim Finden von Begründungen Fehler machen, aber das ist halt so. Manches lernt man erst im Laufe der Zeit und erkennt dann erst (hoffentlich) die eigenen Fehler.

• 2: Wie stehts mit interface? MVC ist ja mehr oder weniger sehr komplex. Da lohnt es sich interface zu verwenden. Ich aber nie sinvoll interfaces verwendet.

Interfaces sind eine Art Vereinbarung. Damit wird vereinbart, dass ein Objekt bestimmte Eigenschaften und/oder Funktionen hat. Das nimmt man vor allem dann, wenn Klassen keinen fachlichen Bezug zueinander haben und damit Vererbung nicht sinnvoll ist, man aber eine gleiche Funktionalität braucht.

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

interface ISerializable {
  function serialize(); // Rückgabewert ist ein String.
  function deserialize($data); // $data ist ein String.
}

Jede Klasse, deren Objekte gespeichert werden müssen, implementiert dieses Interface, sprich: füllt diese vereinbarten Funktionen mit Leben.

class Foo implements ISerializable {
  // anderes Zeugs

  public function serialize() {
    return $daten_als_string;
  }

  public function deserialize($data) {
    this->irgendwas = holeDatenAusDemString($data);
  }
}

Der Mechanismus, der die Daten dann speichert, bekommt Objekte vom Typ ISerializable übergeben. Was die sonst so tun, ist dem Speichermechanismus komplett egal, der muss nur ihre Daten bekommen und braucht deshalb nur Zugriff auf die im Interface vereinbarten Methoden. Alles andere sieht der nicht, zumindest in kompilierten Sprachen. In PHP mit seiner Dynamic könnte man auch daran vorbeiarbeiten.

dedlfix.