PHP Object-oriented design patterns and design principles

First, design Patterns

1. Single-case mode

Purpose: To allow a class to generate only one object

Step: ① the constructor into private

② make a static member function object in a class

③ limiting conditions in the method Riga

    //single-case mode    classren{//Define Human         Public Static $r;//set a static member variable in order to be brought into a static member function         Public $name;//an ordinary member variable that tests whether an object is instantiated only        Private function__construct () {//privatisation constructors, preventing instantiation of objects                        }         Public Static functionDuixiang () {//Create a static member function to access the constructor to instantiate the object            if(Empty(Self::$r)){//setting the limit conditionsSelf::$r=NewRen (); }            returnSelf::$r;//returns the only instantiated object in        }    }        $r= Ren::d Uixiang ();//accessing a static function instantiation object    $r->name = "Zhang San";//assign a value of "Zhang San" to an object's $name    $r 1= Ren::d Uixiang ();//Test If there is only one object    Var_dump($r 1);

Only one object

　　　　

　　

Factory mode

Purpose: To be a factory that specializes in making objects

If a parent class has a large number of subclasses, and the subclass name is not in the same way, you can use this pattern to create the object in a code-named way

    //Factory mode    classjisuan{//define a computed parent class         Public $a;//two common member variables         Public $b;  Public functionJs () {//define a normal member function for a calculation            Echo"Calculation result is"; }         Public function__construct ($a,$b){//constructor that sets the initial value of $ A and $b when instantiating an object            $this->a =$a; $this->b =$b; }        }    classJiaextendsjisuan{//sub-class addition         Public functionJs () {//computed functions for subclasses overridesParent::Js (); return($this->a+$this-b); }        }    classJianextendsjisuan{//sub-class subtraction         Public functionJs () {//computed functions for subclasses overridesParent::Js (); return($this->a-$this-b); }        }    classChengextendsjisuan{//sub-class multiplication         Public functionJs () {//computed functions for subclasses overridesParent::Js (); return($this->a*$this-C); }        }    classChuextendsjisuan{//sub-class division         Public functionJs () {//computed functions for subclasses overridesParent::Js (); return($this->a/$this-b); }        }    classQuyuextendsjisuan{//sub-class take -up         Public functionJs () {//computed functions for subclasses overridesParent::Js (); return($this->a%$this-b); }        }        classgongchang{//define a factory class for producing instantiated objects         Public Static functionDuixiang ($a,$b,$YSF){//set a static member function and pass in the parameter, substituting the name of the subclass for the operation symbol            Switch($YSF){//more branches, using the switch case statement to design different sub-classes and instantiate the object with various operation symbols                 Case"+"; return NewJia ($a,$b);  Break;  Case"-"; return NewJian ($a,$b);  Break;  Case"*"; return NewCheng ($a,$b);  Break;  Case"/"; return NewChu ($a,$b);  Break;  Case"%"; return NewQuyu ($a,$b);  Break; }        }        }    $j= Gongchang::d uixiang (3,2, "%");//Test    Echo $j->js ();//Output

Output results

Second, the design of six major principles

1. The open-close principle is that the design should have good support for the extension, and the modification should be strictly limited.

2. On the Richter scale also, the subclass must be able to replace the base class, otherwise it should not be designed as a subclass.

3. Depending on the switching principle, the design relies on abstraction rather than materialization, in other words, when designing we want to think with abstractions, rather than starting with what classes I need, as these are specific.

4. Interface isolation principle, breaking large interfaces into multiple small interfaces

5. Single duty: One class functions as single as possible, reducing coupling

6. Dimitri rule (least knowledge principle), one object should have as little knowledge of other objects as possible and not speak to strangers

PHP Object-oriented design patterns and design principles