Best practice per la creazione di moduli mediante le classi

Sto cercando di iniziare a costruire i miei moduli come classi ora che lazy / auto-load sono in Drupal 7, e mi piacerebbe guardare alcuni moduli (contrib o core) che stanno facendo un ottimo lavoro.

Esiste un modo creativo per integrare una classe come hook? Devo implementare ogni funzione come un plugin ctools?

Tutti i passanti dovrebbero notare che D7 ha nuove files[]dichiarazioni nei .infofile del modulo per classi / interfacce a caricamento automatico / lento: Scrittura di file .info (Drupal 7.x) .

Di seguito è una buona lettura per ottenere le motivazioni e la costituzione (per così dire) dalla comunità Drupal Programmazione Drupal da una prospettiva orientata agli oggetti .

Un modulo non è una classe di Crell è ciò che dovresti leggere per primo.

La più grande parte di OOP in Drupal 7 è il nuovo livello di astrazione del database (progettato dallo stesso Crell e altri). Ciò implementa molti schemi che possono e devono essere riutilizzati.

Per esempio:

• Definire le interfacce per tutto ciò che potrebbe essere disattivato, lavorare solo contro l'interfaccia internamente. Esempio: SelectQueryInterface
• Una singola classe rappresenta una singola "cosa". Ad esempio, SelectQuery è una query SELECT, DatabaseConnection è una connessione al database e così via. Vedi http://en.wikipedia.org/wiki/Cohesion_(computer_science )
• Uso dell'ereditarietà per consentire di ignorare una determinata implementazione. La maggior parte delle classi in DBTNG può avere una sottoclasse specifica del driver, che viene automaticamente utilizzata e inclusa se esistente. Ad esempio, SelectQuery_mysql . Come è fatto .
• Extender , che sono un'implementazione del modello Decorator per aggiungere funzionalità aggiuntive alla classe SelectQuery. Gli extender possono avere anche sottoclassi specifiche del driver .

Qualcosa che è ancora oggetto di controversia è il nascondere le informazioni . DBTNG lo implementa rendendo protette le proprietà della classe e impedendo l'accesso diretto. D'altra parte, abbiamo hook_query_alter () e possono essere cambiati quasi liberamente con vari metodi di riferimento getter .

Questa è una domanda interessante

L'idea di un modulo Drupal come classe è molto interessante. Tuttavia, anche nei moduli D7 implementano semplicemente funzioni hook che vengono controllate per nome, quindi anche se crei una classe per il tuo modulo dovrai comunque implementare funzioni hook per richiamarle.

Tuttavia, molti moduli utilizzano le classi internamente ed espongono funzionalità tramite queste classi. L'esempio più ovvio sono le viste. Quindi potrebbe essere un buon posto dove cercare. Tuttavia, tieni presente che molti moduli utilizzano le classi a modo loro, quindi ciò che impari guardando le viste potrebbe non essere sempre applicabile.

L'API di entità (il modulo contrib) ti consente di dichiarare una "classe di entità" per ciascuno dei tuoi tipi di entità, quindi tutto il codice relativo alla tua entità (creare, caricare, salvare, accedere, ecc.) Può andare in una classe (vedi come organico Gruppi lo fa, per esempio).

Detto questo, non esagerare. I plugin di ctools sono una buona cosa quando ne hai bisogno (stai scrivendo le prossime Viste, Pannelli o Regole), ma usare le classi ovunque solo per purezza ideologica non ti farà molto bene.