使用类构建模块的最佳实践

现在，由于懒惰/自动加载已在Drupal 7中进行，所以我希望开始将我的模块构建为类，并且我希望查看一些功能出色的模块（contrib或core）。

有没有一种创造性的方式将类集成为钩子？我是否将每个功能都实现为ctools插件？

任何路人都应注意，D7 files[]在模块.info文件中有用于自动/延迟加载类/接口的新声明：编写.info文件（Drupal 7.x）。

以下是从面向对象的角度从Drupal社区获得Drupal编程的动机和构成的良好阅读。

首先应该阅读的模块不是 Crell 的类。

Drupal 7中最大的OOP部分是新的数据库抽象层（由相同的Crell等人设计）。这实现了许多可以并且应该重复使用的模式。

例如：

• 为任何可以切换的接口定义接口，仅在内部针对接口起作用。示例：SelectQueryInterface
• 单个类表示单个“事物”。例如，SelectQuery是SELECT查询，DatabaseConnection是与数据库的连接，依此类推。参见http://en.wikipedia.org/wiki/Cohesion_(computer_science）
• 使用继承可以覆盖某个实现。DBTNG中的大多数类都可以具有特定于驱动程序的子类，该子类会自动使用并包含（如果存在）。例如SelectQuery_mysql。怎么做的。
• 扩展程序，是Decorator模式的一种实现，用于向SelectQuery类添加其他功能。扩展程序也可以具有特定于驱动程序的子类。

那是后话仍然controversaly讨论的是信息隐藏。DBTNG通过保护类属性并禁止直接访问来实现这一点。另一方面，我们具有hook_query_alter（），并且可以通过引用getter方法使用各种方法自由更改它们。

这是个有趣的问题。

将Drupal模块作为类的想法非常有趣。但是，即使在D7模块中，也仅实现了按名称进行检查的挂钩函数，因此，即使为模块创建了一个类，您仍将需要实现挂钩函数来调用它们。

但是，许多模块在内部使用类，并通过这些类公开功能。最明显的例子是视图。因此，这可能是一个不错的地方。但是请注意，许多模块以自己的方式使用类，因此从视图中学习的内容可能并不总是适用。

实体API（contrib模块）允许您为每种实体类型声明一个“实体类”，因此与实体相关的所有代码（创建，加载，保存，访问等）都可以放入一个类中（请参阅有机例如，小组会这样做）。

也就是说，不要过度使用它。当您需要ctools插件时（您正在编写下一个视图，面板或规则），这是一件好事，但是到处使用类仅仅是出于意识形态的纯洁并不会带来太大的好处。