Shulou(Shulou.com)06/03 Report--

This article mainly introduces the PHP design pattern registration tree pattern example analysis, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor with you to understand.

The details are as follows:

What is the registration tree mode?

Of course, the registration tree mode is also called the registration mode, the registry mode. The reason why I am pretentious about its name here is that I find the name of registered tree easier for people to understand. Like the previous two articles, we still start with the name. The registration tree pattern is a pattern design method by registering an object instance to a global object tree and picking from the object tree when needed. This reminds me of buying Tomatoes on sticks when I was a child, and the seller of Tomatoes on sticks inserted Tomatoes on sticks into a big pole, and people took it off when they bought it. The difference is that the registration tree mode will still be picked, can be picked many times, Tomatoes on sticks picked once will be gone.

Why use the registration tree mode?

The singleton pattern solves the problem of how to create unique object instances throughout the project, while the factory pattern solves the method of how to create instance objects without new. So what problem does the registration tree mode want to solve? Before considering this issue, it is still necessary to consider the limitations of the first two models. First of all, the process of creating a unique object in the singleton pattern itself has a judgment, that is, to determine whether the object exists or not. If it exists, the object is returned, and if it does not exist, the object is created and returned. There must be such a layer of judgment every time an instance object is created. The factory model is more concerned with extended maintenance. In general, singleton and factory patterns can produce more reasonable objects. How is it convenient to call these objects? Moreover, the objects so established in the project are like scattered soldiers, so it is inconvenient to manage and arrange them as a whole. Therefore, the registration tree model arises at the historic moment. Whether you generate objects through singleton pattern, factory pattern, or a combination of both, plug them into the registration tree for me. When I use an object, I just take it directly from the registration tree. This is as convenient and practical as we use global variables. And the registration tree pattern provides a very good idea for other patterns.

How to implement the registration tree?

Through the above description, it seems that we can easily find a solution. First of all, there is no doubt that we need a class as a registration tree. All objects are "inserted" into the registration tree. The registration tree should be served as a static variable. And the registration tree should be a two-dimensional array. This class should have a method to insert an object instance (set ()), and when the corresponding should have a method to undo the object instance (_ unset ()). Of course, the most important thing is that you also need a method to read the object (get ()). With these, we can happily complete the registration tree pattern.

Let's make a small combination of the three modes. Simply creating an instance object is far from so complex, but when applied to large-scale projects, the convenience is self-evident.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.