Краща практика побудови модулів за допомогою класів

Я хочу почати будувати свої модулі як класи зараз, коли ледачий / автозавантажений в Drupal 7, і я хотів би подивитися на деякі модулі (contrib або core), які роблять велику роботу з цим.

Чи є творчий спосіб інтегрувати клас як гачки? Чи реалізувати кожну функцію як плагін ctools?

Будь-який перехожий повинен зазначити, що D7 має нові files[]декларації у .infoфайлах модулів для класів / інтерфейсів для автоматичного завантаження / лінивого завантаження: Написання файлів .info (Drupal 7.x) .

Нижче наведено хороше прочитання, щоб отримати мотивації та конституцію (як би) від програми спільноти Drupal Drupal з об'єктно-орієнтованої точки зору .

Crell - це не модуль, який слід прочитати першим.

Найбільша частина OOP в Drupal 7 - це новий рівень абстракції бази даних (розроблений самим Крелом та іншими). Це реалізує багато моделей, які можна і потрібно повторно використовувати.

Наприклад:

• Визначте інтерфейси для всього, що можна було б вимкнути, працюйте лише з інтерфейсом всередині. Приклад: SelectQueryInterface
• Один клас представляє одну "річ". Наприклад, SelectQuery є запитом SELECT, DatabaseConnection - це з'єднання з базою даних тощо. Дивіться http://en.wikipedia.org/wiki/Cousion_(computer_science )
• Використання успадкування, щоб дозволити перекрити певну реалізацію. Більшість класів у DBTNG можуть мати специфічний для драйвера підклас, який автоматично використовується та включається, якщо він існує. Наприклад, SelectQuery_mysql . Як це робиться .
• Розширювачі , які є реалізацією шаблону декоратора для додавання додаткової функціональності до класу SelectQuery. Розширювачі можуть мати і специфічні для драйвера підкласи .

Те, що все ще обговорюється суперечками, - це приховування інформації . DBTNG реалізує це, роблячи захищені властивості класу та забороняючи прямий доступ. З іншого боку, у нас є гак_query_alter (), і їх можна практично вільно змінювати різними методами довідкового геттера .

Це цікаве питання.

Ідея модуля Drupal як класу дуже цікава. Однак навіть у модулях D7 просто реалізувати функції гака, які перевіряються на ім'я, тому навіть якщо ви створюєте клас для свого модуля, вам все одно знадобиться реалізувати функції гака, щоб викликати їх.

Однак багато модулів використовують класи внутрішньо і піддають функціональність за допомогою цих класів. Найбільш очевидний приклад - погляди. Так що це може бути гарним місцем для пошуку. Однак майте на увазі, що багато модулів використовують класи по-своєму, тому те, що ви дізнаєтесь з перегляду поглядів, не завжди може бути застосовно.

API Entity (модуль contrib) дозволяє оголосити "клас сутності" для кожного з типів вашої сутності, тому весь код, пов'язаний з вашою сутністю (створення, завантаження, збереження, доступ тощо), може переходити до класу (дивіться, як Organic Групи це роблять, наприклад).

Це сказало, не перестарайтеся. Плагіни ctools - це хороша річ, коли вони вам потрібні (ви пишете наступні перегляди, панелі чи правила), але використання класів скрізь лише для ідеологічної чистоти не принесе вам великої користі.