View Drupal design from the perspective of Objects

Document directory

• Objects-Object
• Invalid action-Abstraction
• Encapsulation-encapsulation
• Polymorphism-Polymorphism
• Inheritance-Inheritance
• Singleton-singleton
• Decorator-Decoration
• Observer-Observer
• Bridge-Bridging
• Chain of responsibility-responsibility chain
• Command-command
• Improvements

Drupal programming from an object-oriented perspective

Currently, no direct evidence of using OOP is available in Drupal source code or API interfaces (for example, the definition of Class is not visible in some places where class should be clearly used ), this has aroused a lot of criticism for Drupal, which is regarded as a non-trendy shortcoming of Drupal. it is true that Drupal does not directly use PHP's OOP features, but it still applies a lot of OO design principles in Drupal design. this article describes the Drupal system architecture from the perspective of objects, so that OOP programmers can correctly evaluate Drupal from the perspective of OO design principles, I hope that this article will give readers a better understanding of Drupa. with the maturity of PHP and Drupal in the future, Drupal will introduce more and more php oop features.

Motivation and reason of Current Design

Since Drupal released version 4.6, Drupal has decided not to use the PHP class any more. This decision comes from the following reasons:

First, we were still using PHP 4 when designing Drupal. At that time, PHP 4's support for oo was not mature until PHP 5 was released.

Second, PHP significantly reduces the performance when loading a large amount of code, especially when PHP accelerator (Zend) is not available: during the test, the time required for PHP to compile the Drupal page source code accounted for more than half of the entire process. to solve this critical problem, Drupal uses "delayed loading", so that each page request only loads the part of the Code actually needed. this method works well in Drupal "module-function-hook" mode, but PHP does not support application in class. this leads to either enduring "slowness (loading a large number of PHP Code defining the class)" or "disorder (in the index. PHP writes a lot of logic code to reduce the amount of code loading) ", obviously this is unacceptable.

Finally, some OOP design principles are that PHP is not supported or not supported when Drupal is ready for use. for example, Drupal wants to use a type similar to objective-C's "categories" in Theme system, (ruby-'open classs', JavaScript-'modifying object prototypes ', C #-'extension Methods '). the core of this idea is that the class can be defined multiple times. You can define the same class in different places. in this way, the function of a class can be extended without modifying the original definition. It is very consistent with the "open-close" principle in Ood, that is, "open-close to extension" for modification ".

There will be some changes in the coming Drupal 7: Drupal 7 will force PHP 5 to bring a lot of convenience to introduce Oop, and it will also start to use class in some modules. however, the core structure of Drupal still does not use class.

OOP in Drupal

 

Although the class is not explicitly used in Drupal, some oo features are still used in Drupal design. we can find the essential features in an OO design system in Drupal design according to OO specifications.

Objects-Object

Drupal has many elements that comply with the descriptions of "objects" in OOP specifications. the modules, themes, nodes, and uses components can be seen as "objects.

A node is the most basic information component in a Drupal site. It represents all types of information data in a typical information publishing system. generally, the system defines the node by calling the node_invoke () function. module. the "user" object contains the site account data, user-defined data, and session information. the data structures of these objects are defined in the database by using data tables instead of class. because Drupal uses relational databases, this allows other modules to expand these objects by attaching data.

Modules and themes are also an object. In many aspects, they all act as "controllers. A module is not only a source file, but also a collection of related functions and an important component of the Drupal-defined hook system.

Invalid action-Abstraction

Drupal's hook system (or Callback System) can be seen as an interface implementation. "Hook" defines the operations that can be performed on or by the module. If the module implements a hook, it is equivalent to a contract for executing a specific task or returning specific information. the caller can call the hook without knowing the module and hook implementation details.

Encapsulation-encapsulation

Drupal does not adopt strict "Access Control" in the implementation of encapsulation features. It uses "naming conventions ". drupal code is based on functions. All functions are in a namespace. The system can divide the sub-spaces by the prefix in the function name. you can use the simple "Naming Convention" module to define private functions and variables without conflict.

Naming Conventions can also define public interfaces from functions in a module. the private function name is prefixed with "_". The external module should not access the function named in another module. for example, _ user_categories () is a private function. It is not agreed and unsafe to directly access it from the outside. Any changes to it are not announced in advance. user_save () is the public interface (API) of the user module. by calling this function, you can safely save user objects to the database.

Polymorphism-Polymorphism

Generally, "nodes" have multiple forms (common pages and story). If a module displays a "Node" on the page ", call node_build () on the "Node" and then call drupal_render () to obtain the HTML code containing the "Node" content. the actual rendering process (the process of getting HTML code) depends on the type of the input "Node", which is similar to a type object that determines its behavior based on the received message. drupal implements tasks that are usually completed in the OOP Language Runtime Library.

In addition, in the above example, the rendering of "Node" will be affected by the current topic. the appearance of a "topic" varies, but the interface is inconvenient. "topic" adds a specific Appearance Effect to "Node" by processing "rendering node" messages, the specific visual effect depends on the implementation of the current topic.

Inheritance-Inheritance

The module and topic can be viewed as the types inherited from the "abstract class. for the "theme class", the method of "abstract class" is defined in theme. in Inc, the default implementation is provided by the activated modules in the system. Custom themes can overwrite the display of any interface component. the same is true for the "module". The hook api of the "module" is optional during implementation.

Design Patterns in Drupal

The internal structure of Drupal is mostly complex, and simple design like inheritance and polymorphism can no longer be able to handle them well. the exciting system features are the results of the application of mature design patterns. many design patterns described in <Design Patterns> ("Gang of Four") are applied in Drupal, for example:

Singleton-singleton

If we regard "module" and "topic" as objects, these objects are all applied in the singleton mode. generally, these "objects" do not contain data. The way to distinguish them is to look at the functions they contain, which can be seen as a class with only one instance.

Decorator-Decoration

The decoration mode is widely used in Drupal. in our previous discussions, we mentioned that the Node object has multiple forms, but this is only a small part of the functions of the node system. more notably, any module can extend the functions of all node objects by implementing node hooks (such as hook_node_load () and hook_node_view.

This feature can be used to expand multiple functions for node without "subclass. for example, Drupal's built-in news report node contains only the title, author, Content abstract, and body attributes. now you need to add a common feature-additional file for it, one way is to design a new node type, the new type will include all the functions of news reports and add the additional file function. drupal's upload module adopts a more modular and more concise and powerful method to achieve this requirement, by using the node API, it can add additional files for any node type.

The implementation of the Drupal upload module is similar to Wrapping each node object in the decorator mode. in the Objective-C language that supports the categories feature, you can easily add features to all node objects by extending the node base class features. drupal uses the hook system to call the node_invoke () function to simplify the process.

Observer-Observer

The above demonstration of Node object function extension is similar to using the observer mode in the OO system. the observer mode can be said to be ubiquitous in Drupal. In essence, the hook system allows modules to be registered as the observer of Drupal objects. for example, when you modify a vocabulary in the Drupal classification system, the hook system calls all modules that implement hook_taxonomy_vocabulary_update. by registering the hook module of the classification system as the observer of the vocabulary, any modifications to the vocabulary will notify the observer as appropriate.

Bridge-Bridging

The implementation method of the database abstraction layer of Drupal has some Bridge pattern marks. when writing a module, you must use the database abstraction layer to access data, avoiding the use of specific database features. in this way, you do not need to modify the code of the existing module when changing the database.

Chain of responsibility-responsibility chain

Drupal's menu system follows the responsibility chain mode during design. for each page request, the menu system determines whether a module is used to process the request, whether the current user has the permission to access the requested resource, and which function must be called to process the request. to achieve this, the system will send the Request Path to the menu item. If the current menu item cannot process this request, it will be sent to the next link of the responsibility chain, the request will not end until a module processes the request, or the module rejects the access from the current user, or there is no subsequent link in the responsible chain.

Command-command

Many Drupal hooks use the command mode to reduce the number of functions that must be implemented (in addition to passing normal parameters and passing required operations as parameters ). in fact, the hook system also uses the command mode to support the module and only defines the hook for the operations they are concerned about.

Why not use classes.

I hope that the way in which Drupal implements the OOP concept can be clearly stated here. So, why does Drupal not tend to use classes instead of existing designs in the future? Some of the reasons are historical issues. More importantly, since we have a way to apply the OO design pattern in Drupal, why must we use classes.

A good example is about the scalability of the topic system. If you want to implement a new interface topic, the idea of OOP is to inherit a new class from the default topic class. when the new topic needs to support an interface element not supported by the base class, there is no simple way to use it. drupal's Theme system uses the function distribution system to solve this problem concisely and elegantly. in this case, classes makes the system concise and clear on the surface, but it also makes the system stiff and difficult to expand.

Improvements

Although Drupal has implemented many multi-object practices, it needs to be improved in some aspects.

Encapsulation, although fully designed, is not well implemented during code writing. public and private functions of the module should be strictly designed, but most functions are more exposed during execution, even if some functions have to change frequently. in addition, the backward compatibility policy when Drupal is updated makes this problem increasingly serious. this backward compatible policy requires better encapsulation execution to bring better benefits to the system.

Inheritance: there are not many applications in the system. As mentioned above, all modules share public interfaces, and it is difficult to extend to new modules. it is easy to use a new module to expand the functions of an existing module, but there is no way to rewrite a module. we can break down large modules into small function libraries to reduce the problems that modules bring to the system.