PHPV5.3 activates object-oriented programming with delayed static binding

PHPV5.3 solves some problems of object-oriented programming (OOP) through its delayed static binding (LSB) feature. Learn how LSB fixes php oop programming problems and how to implement some well-known object-oriented design patterns that require LSB. Object-oriented programming (OOP) allows developers to <LINKhref = "http :/

PHP V5.3 solves some problems of object-oriented programming (OOP) through its delayed static binding (LSB) feature. Learn how LSB fixes php oop programming problems and how to implement some well-known object-oriented design patterns that require LSB.
Object-oriented programming (OOP) allows developers to reduce and simplify code by using data abstraction, encapsulation, modularity, polymorphism and inheritance-with a deep understanding of OOP. An understanding of OOP features also allows PHP programmers to use design patterns-some well-known algorithms used to solve common problems. PHP has provided the OOP function since V3.0, but the odd features in PHP's OOP implementation will still prevent the use of some common design patterns when V5.3 arrives. With the advent of PHP V5.3's delayed static binding (LSB) feature, these strange features have completely disappeared.

This article introduces some problematic design patterns before PHP V5.3 and explains why these patterns cannot work. The LSB features of PHP V5.3 are displayed, and the singleton and activity record design modes are provided.

Review OOP

If you have been familiar with php oop in the past, you may choose not to use it for the following reasons:

I have read one of the many blog posts that claim that PHP OOP is faulty.

I tried to implement a simple design pattern, but it was not successful.

For PHP V5.3, The Post on OOP is positive, and the problem of php oop has been largely solved. It's time to go back to php oop. Through this article, you will see some design patterns that had problems before V5.3: Singleton, generator, Factory method, and activity records.

Singleton, generator, and factory method design patterns are considered as creation patterns because they can assist in object building. The Singleton mode may be one of the most common OOP design patterns; it limits the number of object instances of a class to only 1. For example, the database connection pool is an example of the Singleton design mode: we generally do not want applications to have multiple resource-intensive instances with connection pool classes.

When you need to separate the construction and representation of complex objects, you need to use the generator design pattern. You can use the same constructor to create multiple objects. The implementation of the generator mode can be complex, but once the generator is available, it can simplify the construction and use of the objects created by the generator. An example of using a generator is a transformer with the ability to output HTML, XML, or PDF.

The factory method mode, as its name implies, defines the implementation of a method that is used to produce a large number of objects. You can use the factory method mode when an application needs to create an object whose type depends on the implementation of the subclass.

The activity record mode can be used to wrap the relational database persistence method in the domain class. Each instance of an activity record is related to a specific row in the database. This class contains methods for inserting, deleting, and updating one or more rows in the database. The activity logging design pattern is defined by Martin Fowler in Patterns of Enterprise Application Architecture and is becoming increasingly popular with Ruby on Rails.

Front-LSB creation design mode implementation problems

All the four design patterns mentioned above use static attributes and methods. For example, check the connection pool Singleton shown in listing 1.

Listing 1. A simple Singleton

Class ConnPool {
Private static $ onlyOne;
Private static $ count = 0;
Private function _ construct (){
// Real-world db conn stuff here...
}

Public static function getInstance (){
If (! Is_object (self: $ onlyOne )){
$ Klass = _ CLASS __;
Self: $ onlyOne = new $ klass ();
Self: $ count ++;
}
Return self: $ onlyOne;
}
Public static function getInstanceCount () {return self: $ count ;}
}

$ Db = ConnPool: getInstance ();
Assert (1 = $ db-> getInstanceCount ());
$ Db2 = ConnPool: getInstance ();
Assert (1 = $ db2-> getInstanceCount ());
?>
Note the static $ onlyOne variable. This variable is designed to save an instance of the connection pool object. The static modifier before $ onlyOne relates this variable to the class itself. The $ onlyOne variable is a class attribute because its scope is this class. The $ onlyOne attribute has only one instance. When an attribute does not have a static modifier, it is called an object attribute, because this attribute is unique to every instance of the class.

Note that the ConnPool constructor method (called _ construct) is empty. In a production implementation, you can use this method to create the interval between database connection pools.

The static getInstance method contains the template code of the singleton. A $ onlyOne instance is created only when the static $ onlyOne variable is null. Note how to use the _ CLASS _ variable to obtain the CLASS type and then create an instance of the CLASS.

The getInstanceCount method is only used to prove that only one instance in the connection pool is created. The four lines of code at the bottom of listing 1 prove that no matter how many times a ConnPool pool class is requested for an instance, it will return the same object.

So, so far, this Singleton is normal-until you decide to subclass the connection pool in the form of an object-oriented inheritance tree to support multiple databases. Listing 2 shows the inheritance tree (for clarity, the instance counter and constructor code are deleted ).

Listing 2. A failed attempt on the singleton without LSB

Class ConnPool {
Private static $ onlyOne;
Protected static $ klass =__ CLASS __;

Public static function getInstance (){
If (! Is_object (self: $ onlyOne )){
Self: $ onlyOne = new self: $ klass ();
}
Return self: $ onlyOne;
}
}

Class ConnPoolAS400 extends ConnPool {
Protected static $ klass =__ CLASS __;
}
$ Db = ConnPoolAS400: getInstance ();
Assert ('connpoolas400' = get_class ($ db); // fails
?>
To support multiple types of Singleton classes, the ConnPool class adds a $ klass static variable and assumes that it will be overwritten in the subclass. The ConnPoolAS400 subclass extends the ConnPool class and provides its own version of the $ klass attribute. We expect that when an instance of the ConnPoolAS400 class is created, the $ klass attribute will save the ConnPoolAS400. But when the code is executed, it does not run as expected. When the PHP utility function get_class returns ConnPool instead of ConnPoolAS400, the declaration at the bottom of the code fails. The problem is that the getInstance method of the ConnPool class uses its own $ klass attribute version instead of the ConnPoolAS400 overwrite version.