Meilleure pratique pour créer des modules à l'aide de classes

Je cherche à commencer à construire mes modules en tant que classes maintenant que lazy / auto-load sont dans Drupal 7, et j'aimerais regarder certains modules (contrib ou core) qui font un excellent travail.

Existe-t-il un moyen créatif d'intégrer une classe en tant que hooks? Dois-je implémenter chaque fonctionnalité en tant que plugin ctools?

Tout passant devrait noter que D7 a de nouvelles files[]déclarations dans les .infofichiers de module pour les classes / interfaces de chargement automatique / paresseux: Écriture de fichiers .info (Drupal 7.x) .

Ce qui suit est une bonne lecture pour obtenir les motivations et la constitution (pour ainsi dire) de la programmation Drupal de la communauté Drupal dans une perspective orientée objet .

Un module n'est pas une classe de Crell, c'est ce que vous devez lire en premier.

La plus grande partie de la POO dans Drupal 7 est la nouvelle couche d'abstraction de base de données (conçue par le même Crell et d'autres). Cela met en œuvre de nombreux modèles qui peuvent et doivent être réutilisés.

Par exemple:

• Définissez les interfaces pour tout ce qui pourrait être désactivé, ne travaillez que contre l'interface en interne. Exemple: SelectQueryInterface
• Une seule classe représente une seule "chose". Par exemple, SelectQuery est une requête SELECT, DatabaseConnection est une connexion à la base de données, etc. Voir http://en.wikipedia.org/wiki/Cohesion_(computer_science )
• Utilisation de l'héritage pour permettre de passer outre une certaine implémentation. La plupart des classes de DBTNG peuvent avoir une sous-classe spécifique au pilote, qui est automatiquement utilisée et incluse si elle existe. Par exemple, SelectQuery_mysql . Comment cela se fait .
• Extendeurs , qui sont une implémentation du modèle Decorator pour ajouter des fonctionnalités supplémentaires à la classe SelectQuery. Les extensions peuvent également avoir des sous-classes spécifiques au pilote .

Quelque chose qui est encore controversé est la dissimulation d'informations . DBTNG implémente cela en rendant les propriétés de classe protégées et en interdisant l'accès direct. D'autre part, nous avons hook_query_alter () et ils peuvent être modifiés presque librement avec diverses méthodes getter par référence .

C'est une question intéressante.

L'idée d'un module Drupal en tant que classe est très intéressante. Cependant, même dans les modules D7, implémentez simplement des fonctions de hook qui sont vérifiées par leur nom, donc même si vous créez une classe pour votre module, vous devrez toujours implémenter des fonctions de hook pour les appeler.

Cependant, de nombreux modules utilisent des classes en interne et exposent des fonctionnalités via ces classes. L'exemple le plus évident est celui des vues. C'est donc peut-être un bon endroit où chercher. Cependant, sachez que de nombreux modules utilisent les classes à leur manière, donc ce que vous apprenez en regardant les vues peut ne pas toujours être applicable.

L'API d'entité (le module contrib) vous permet de déclarer une "classe d'entité" pour chacun de vos types d'entité, afin que tout le code lié à votre entité (créer, charger, enregistrer, accéder, etc.) puisse aller dans une classe (voir comment Organic Les groupes le font, par exemple).

Cela dit, n'en faites pas trop. Les plugins ctools sont une bonne chose lorsque vous en avez besoin (vous écrivez les prochaines vues, panneaux ou règles), mais utiliser des classes partout juste pour la pureté idéologique ne vous fera pas beaucoup de bien.