Best Practice für das Erstellen von Modulen mit Klassen

Ich versuche, meine Module jetzt als Klassen zu erstellen, in denen Lazy / Auto-Load in Drupal 7 enthalten ist, und ich würde mir gerne einige Module (Contrib oder Core) ansehen, die einen großartigen Job machen.

Gibt es eine kreative Möglichkeit, eine Klasse als Hooks zu integrieren? Implementiere ich jede Funktion als ctools-Plugin?

Passanten sollten beachten, dass D7 neue files[]Deklarationen in Moduldateien .infofür Klassen / Interfaces zum automatischen / verzögerten Laden hat: Schreiben von .info-Dateien (Drupal 7.x) .

Das Folgende ist eine gute Lektüre, um die Motivationen und die Konstitution (sozusagen) der Drupal-Community Drupal-Programmierung aus einer objektorientierten Perspektive zu erhalten .

Ein Modul ist keine Klasse von Crell, die Sie zuerst lesen sollten.

Der größte OOP-Teil in Drupal 7 ist die neue Datenbankabstraktionsschicht (von Crell und anderen entwickelt). Das implementiert viele Muster, die wiederverwendet werden können und sollten.

Beispielsweise:

• Definieren Sie Schnittstellen für alles, was ausgeschaltet werden könnte. Arbeiten Sie nur intern mit der Schnittstelle. Beispiel: SelectQueryInterface
• Eine einzelne Klasse repräsentiert ein einzelnes "Ding". Beispielsweise ist SelectQuery eine SELECT-Abfrage, DatabaseConnection eine Verbindung zur Datenbank usw. Siehe http://en.wikipedia.org/wiki/Cohesion_(computer_science )
• Verwendung der Vererbung zum Überschreiben einer bestimmten Implementierung. Die meisten Klassen in DBTNG können eine treiberspezifische Unterklasse haben, die automatisch verwendet und eingeschlossen wird, falls vorhanden. Zum Beispiel SelectQuery_mysql . Wie das geht .
• Extender , eine Implementierung des Decorator-Musters , um der SelectQuery-Klasse zusätzliche Funktionen hinzuzufügen. Extender können auch treiberspezifische Unterklassen haben .

Was immer noch kontrovers diskutiert wird, ist das Verbergen von Informationen . DBTNG implementiert dies, indem Klasseneigenschaften geschützt werden und der direkte Zugriff nicht zugelassen wird. Andererseits haben wir hook_query_alter () und sie können mit verschiedenen Referenz-Getter- Methoden fast frei geändert werden.

Das ist eine interessante Frage.

Die Idee eines Drupal-Moduls als Klasse ist sehr interessant. Selbst in D7-Modulen implementieren Sie einfach Hook-Funktionen, die namentlich geprüft werden. Selbst wenn Sie eine Klasse für Ihr Modul erstellen, müssen Sie Hook-Funktionen implementieren, um sie aufzurufen.

Viele Module verwenden Klassen jedoch intern und stellen die Funktionalität über diese Klassen zur Verfügung. Das offensichtlichste Beispiel sind Ansichten. Das könnte also ein guter Ort sein, um nachzuschauen. Beachten Sie jedoch, dass viele Module Klassen auf ihre eigene Weise verwenden, sodass das, was Sie aus der Betrachtung von Ansichten lernen, möglicherweise nicht immer anwendbar ist.

Mit der Entity-API (dem Contrib-Modul) können Sie für jeden Ihrer Entitätstypen eine "Entitätsklasse" deklarieren, sodass der gesamte Code, der sich auf Ihre Entität bezieht (Erstellen, Laden, Speichern, Zugriff usw.), in eine Klasse aufgenommen werden kann (siehe Organic) Gruppen macht es zum Beispiel).

Das heißt, übertreib es nicht. ctools-Plugins sind eine gute Sache, wenn Sie sie brauchen (Sie schreiben die nächsten Views, Panels oder Rules), aber Klassen überall nur aus Gründen der ideologischen Reinheit zu verwenden, hilft Ihnen nicht viel.