Three design patterns commonly used in PHP

This article introduces three kinds of commonly used PHP design patterns: Singleton mode, Factory mode, observer mode, the need for friends can refer to.

First, the singleton mode

A singleton pattern is to ensure that a class has only one instance, and that it instantiates itself and provides this instance to the entire system, that is, only one instance of the class exists in the application.
The singleton pattern is typically used in instances where only the database access object is allowed, thus preventing multiple database connections from being opened, and the singleton pattern is a common design pattern, in which the drivers for the thread pool, cache, log objects, dialogs, printers, database operations, graphics cards are often designed as singleton cases.

A singleton class should include the following points:
Unlike ordinary classes, a singleton class cannot be instantiated directly, but only by its own instantiation. Therefore, to achieve such a restrictive effect, the constructor must be marked private.
In order for a singleton class to function without being instantiated directly, you must provide an instance of it. Therefore, the Singleton class must have a private static member variable that can hold an instance of the class and a corresponding public static method that can access the instance.
In PHP, in order to prevent the cloning of a singleton class object to break the above implementation form of the Singleton class, usually also provides an empty private __clone () method for the base. Well, not much nonsense to say, summarized as follows

The singleton mode has the following 3 features:

1. There can be only one instance, must have a constructor, and must be marked private

2. This instance must be created on its own, with a static member variable that holds an instance of the class

3. You must provide this instance to other objects and have a public static method that accesses this instance

A singleton class cannot be instantiated directly in any other class, but only by its own instantiation. Instead of creating an instance copy, it returns a reference to the instance stored inside the Singleton class

So why use PHP singleton mode?

A major application of PHP is the application of the database to deal with the scene, there will be a large number of database operations in an application, the database handle connection to the database behavior, using a singleton mode can avoid a large number of new operations. Because each new operation consumes both system and memory resources.

In previous project development, the situation before using the singleton pattern was as follows:

Initializes a database handle $db = new db (...); /For example, there is an application scenario that adds a comment message $db->addcomment ();.//If we are going to use this comment information in another place, then we will be using the database handle resource, we might do this ... function comment () {$　　　db = new db (...);　　　$db->getcommentinfo (), ...//Maybe some friends may say that you can use the Global keyword directly! Global $db, .....

It is true that global solves the problem and acts as a singleton, but in OOP we recommend rejecting the code. Because global has a security risk (the nature of the globally variable is not protected).

Global variables are one of the main causes of bugs encountered by object-oriented programmers. This is because global variables bundle classes in a particular environment, destroying encapsulation. If the new application does not guarantee that the same global variables are defined at the outset, a class that relies on a global variable cannot be extracted from an application and applied to a new application.

To be exact, the singleton pattern is just an improvement on global variables to avoid polluting namespaces with global variables that store unique instances. You cannot overwrite a single case with the wrong type of data. This protection is especially important in PHP versions that do not support namespaces. Because naming conflicts in PHP are captured at compile time, and the script stops running.

We use the singleton pattern to improve the following example:

Class Single {    private $name;//Declare a private instance variable private    function __construct () {//Declare private constructor method in order to prevent external code from using new to create the object.        }    static public $instance;//declares a static variable (a unique instance saved in the Class) static public    function getinstance () {//Declares a getinstance () static method, Used to detect if there is an instance object        if (!self:: $instance) Self:: $instance = new self ();        Return self:: $instance;    }    Public Function SetName ($n) {$this->name = $n;}    Public Function GetName () {return $this->name;}} $oa = Single::getinstance (); $ob = Single::getinstance (); $oa->setname (' Hello php world '); $ob->setname (' Good Morning php '); Echo $oa->getname ();//good morning Phpecho $ob->getname ();//good Morning PHP

Advantages and disadvantages of the singleton model:

Advantages:

1. Improve the design of the system

2. is an improvement of the global variables

Disadvantages:

1. Difficult to debug

2. Hidden dependencies

3. Unable to overwrite a single case with the wrong type of data

Second, the factory model

A factory pattern is a class, which is a class that contains a method that is designed to create other objects, and the factory class is essential in the practice of polymorphic programming, which allows for dynamic substitution of classes, modification of configurations, and often makes applications more flexible, and it is important to master the advanced PHP developers in Factory mode.

Factory mode is typically used to return different classes that conform to similar interfaces, a common use of factories is to create polymorphic providers, allowing us to determine which class should be instantiated based on application logic or configuration settings, for example, you can use such a provider to extend a class without refactoring other parts of the application. This will use the new extended name.

Typically, the factory pattern has a key construct, named Factory static method according to general principle, however this is only a principle, the factory method can be arbitrarily named, this static can also accept arbitrary data parameters, must return an object.

There are some methods for creating objects for you, so that you can use the factory class to create objects, and the factory pattern is that you can create a class that is designed to implement and return instances of other classes, based on input parameters or application configuration, without using new directly, so that if you want to change the type of object created, Just change the factory,

Let me give you an example:

<?phpclass Factory {//Create a basic factory class    static public function FAC ($id) {//Create a static method that returns an instance of an object        if (1 = = $id) return new A ( );                ElseIf (2== $id) return new B ();                ElseIf (3== $id) return new C ();                return new D ();}    } Interface Fetchname {//Create an interface public    function GetName ();//}class a implements fetchname{    private $name = "AAAAA" ;    Public Function GetName () {return $this->name;}} Class C implements fetchname{    private $name = "CCCCC";    Public Function GetName () {return $this->name;}} Class B implements fetchname{    private $name = "bbbbb";    Public Function GetName () {return $this->name;}} Class D implements fetchname{    private $name = "ddddd";    Public Function GetName () {return $this->name;}} $o = FACTORY::FAC (6);//Call the method in the factory class if ($o instanceof fetchname) {  echo  $o->getname ();//ddddd} $p =factory:: FAC (3); Echo $p->getname ();//ccccc?>

Personal opinion, say simple, the PHP Factory mode is to use a factory method to replace the operation of the direct new object, is to facilitate the extension, easy to use, in the new implementation of the class in the base class method, then in the factory class without modification, the incoming parameters can be used directly, in particular, skip the factory class modification, Directly use the factory class to output the desired results. In traditional practice, if you want to generate a class, you are going to create a new object in your code, such as:

Class database{    } $db = new Database ();

Here's how to do the Factory mode:

Class database{   }//Create a factory class classes factory{   //Create a static method for the Statics   function CreateDatabase () {          $db = new Database;          return $db;   }}

So, when we want to create a database class, we can use this method:

<?php     $db = Factory::createdatabase ();? >

The advantage of a simple Factory mode is that the database class is used in many PHP files, such as the database class, when some changes have been made to the object, such as modifying the class name, or some parameters have changed, if you are using $DB = new Database, the traditional method of generating objects, then in all the PHP file containing this generated object code to be modified. Instead, use the Factory mode, as long as the factory method or class inside the modification can be. And the factory model is the basis for other design patterns.
Further optimization of the simple factory pattern above, such as:

Use factory class to produce objects:

<?phpclass example{    //The Parameterized factory method public    static function factory ($type)    {        if ( Include_once ' drivers/'. $type. '. php ')     {            $classname = ' driver_ '. $type;                return new $classname;        }         else         {                    throw new Exception (' Driver not Found ');}}    //Load a MySQL driver$mysql = Example::factory (' MySQL '); Load an SQLite driver$sqlite = example::factory (' SQLite '); >

The simple factory model is also called the Static factory method mode. From the name you can see that this pattern must be very simple. The purpose of its existence is simple: Define an interface for creating objects.
To understand the concept of a factory model, let's talk about the arduous journey of many developers working on large systems. A problem occurs when you change a code fragment, and other parts of the system--the ones you thought were completely unrelated--might also have cascading corruption.
The problem is tight coupling. Functions and classes in a part of the system depend heavily on the behavior and structure of functions and classes in other parts of the system. You need a set of patterns that enable these classes to communicate with each other, but do not want to tightly bind them together to avoid interlocking.
In large systems, many of the code relies on a few key classes. There may be difficulties when you need to change these classes. For example, suppose you have a User class that reads from a file. You want to change it to another class read from the database, but all code references the original class that was read from the file. At this point, it is convenient to use the Factory mode.

Look at the following example:

<?php     interface Iuser    {      function getName ();    }     Class User implements Iuser    {public              $id;      Public function __construct ($id) {} public       function GetName ()      {        return "fantasy";      }    }? >

Traditional methods use the user class, which is generally the case:

<?php//on page 1$obj = new User (1); on page 2$obj2 = new User (2); on page 3$obj3 = new User (3); >

At this time, because of the new requirements, so that the user class to add a parameter or user class name changes, the user class code changes, namely:

<?phpclass User implements iuser{public  $id, $pre;  Public function __construct ($id, $pre = ") {...}   Public Function GetName ()  {    return $this->pre. " Fantasy ";  }}? >

Then, the horrible thing happened, assuming that there were 100 previous pages referencing the previous User class, then the 100 pages would have to be changed accordingly:

on page 1$obj = new User (1, ' AAA '); on page 2$obj = new User (2, ' AAA '); on page 3$obj = new User (3, ' AAA ');

It was a small change, but the reason for the tight coupling made the change vomit. This can be avoided by using the Factory mode:

The User class is the pre-change class userfactory{public  static function Create ($id)  {    return new User ($id);  }}//Page 1$uo1 = Userfactory::create (1); Page 2$uo12 = userfactory::create (2);....

When demand changes, the User class also changes:

<?phpclass User implements iuser{public  $id, $pre;  Public function __construct ($id, $pre = ") {...}   Public Function GetName ()  {    return $this->pre. " Jack ";  }}? >

However, we no longer need to change these 100 pages, we have to change only this factory class:

Class userfactory{public  static function Create ($id, $pre = ' aaa ')  {    return new User ($id, $pre);  }}

The other 100 pages do not have to make any changes, this is the factory design mode benefits. Look at the UML diagram:

Third, the Observer pattern
The Observer pattern gives you another way to avoid tight coupling between components. The pattern is very simple: The Observer pattern is an event system, meaning that this pattern allows a class to observe the state of another class, and when the observed class state changes, the observation class can receive notifications and make corresponding actions;

Now there are two factions, some people recommend the use of design patterns, some people do not recommend the use of design mode!
This is like writing articles, some people like the article follow the routines, such as narrative nature of the article, time, place, character, events. And some people like to write essays or essays, some people like to write poetry!
Writing code now is a lot like writing articles, but in some places you need more skills than writing articles! Write articles written more generally can also write excellent articles, and code is the same, write more can also write a lot of code!
Many times, when I look at design patterns, some design patterns just match my code habits. But if you try to set it up, it's counterproductive. --many times is learned the moves, in the application unconsciously use these moves, can grasp its way, but also do not rigidly adhere to the moves, is so-called "no recruit wins has the recruit"?

I'm learning design patterns, and that's what I know about this stuff. I have such an impression in my mind that I will not give birth to it! If design patterns don't fit your habits, it's bad for you to read the code!

The Observer pattern defines a one-to-many dependency on an object, so that when an object changes state, all its dependents are notified and updated automatically!

Design Principles

In the Observer pattern, the state of the subject and the number of observers are changed. With this pattern, you can change objects that depend on the subject state, without changing the theme. --Find out what is going to change in the program, and then separate it from the fixed aspect!

Both themes and observers use interfaces: The Observer uses the interface of the topic to register the subject, and the subject uses the Observer interface to notify the Observer. This allows the two to function normally, but also has the advantage of loose coupling! --Programming for the interface, not for the implementation of programming!

The Observer pattern uses "combination" to combine many observers into the subject. This relationship between objects (the Observer-subject) is not generated by inheritance, but by the way the composition is used at run time. --Multi-use combination, less use inheritance!

Well, don't say too much nonsense, directly on the code:

<?php/** * Viewer mode * @author: Fantasy * @date: 2017/02/17 */class paper{/* Theme *    /private $_observers = Array (); Public     function Register ($sub) {/*  Register Observer */        $this->_observers[] = $sub;    }         Public Function trigger () {/  *  External Unified Access    */        if (!empty ($this->_observers)) {                    foreach ($this- >_observers as $observer)                    {                                    $observer->update ();}}}    }/** * The interface to be implemented by the viewer */interface observerable {public    function Update (),} class Subscriber implements observerable{public    function Update () c19/>{        echo "callback\n";    }? >

Here is the test code:

  /* Test    */$paper = new paper (); $paper->register (New Subscriber ());//$paper->register (New Subscriber1 ()) ;//$paper->register (New Subscriber2 ()); $paper->trigger ();

Summarize

When a new object is to be filled in, it needs only to be registered in the subject (also known as an observer) (there are many ways of registering it, you can also register it at the time of construction, or in the interface that the framework accesses), and then the implementation code is directly in the interface of the new object. This reduces the coupling of the subject object and the Observer object.

A good design pattern does not go directly into your code, but into your brain.