设计模式

Posted 2020-09-15 <一>

1.单例模式：针对于一个场景来说的(为了控制对象的数量，只能够有一个对象，相当于类的计划生育)

做法：
1.将类的构造函数写成私有的
2.在类中作了一个公有的函数来造对象
3.将该函数变成静态的
4.在函数中加控制（判断）

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

class Ren {     public $name;     static public $dx;   //2.造一个成员变量来存储该对象,将来是要放到方法中的，所以设成静态的     <br>　　　　 private function __construct()  //1.构造函数写成私有的：这样是可以防止无限制的造对象     {<br>　　　　　}<br>     //3.写一个静态方法：在外界就可以调用；如果是普通方法是不能调的，因为要用对象调，不能造对象，自然不能调用     static function Dui()     {         //4.在函数中加控制：判断公有的对象是否为空，为空造对象，不为空则是返回这个对象         if(empty(self::$dx))         {         　　self::$dx = new Ren();    //用self调用         }         return self::$dx;      }   }   $r = Ren::Dui();  //调用方法 $r->name = "张三";  //赋值   $r1 = Ren::Dui(); //$r1->name="张思";   var_dump($r1);

得出的结果就是，如果$r1没有给name赋值，那么输出$r1的结果就是$r的name值，也就是$r1就是$r；若$r1赋值后，输出的就是自己的赋值

      

 

2.工厂模式
类很多的时候可以用市场switch
类少可以用if

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

abstract class YunSuan    //抽象类 {     public $a;     public $b;           function Suan()     {     } }     class Jia extends YunSuan {     function Suan()     {     　　return $this->a+$this->b;     } }   class Jian extends YunSuan {     function Suan()     {     　　return $this->a-$this->b;     } }   class Cheng extends YunSuan {     function Suan()     {     　　return $this->a*$this->b;     } }   //做一个工厂类 class GongChang {     static function ShengChan($fuhao)     {         switch($fuhao)         {             case "+":                 return new Jia();                 break;             case "-":                 return new Jian();                 break;             case "*":                 return new Cheng();                 break;         }     } }   //算加法 $suan = GongChang::ShengChan("+");    //可以换成ShengChan中的任何算法 $suan->a = 10; $suan->b = 5; echo $suan->Suan();

 

OOP基本上有6大原则，而实际上都是互补的，也就是说一些原则需要利用另一些原则来实现自己。6大原则如下：

1) Open-Close Principle（OCP），开-闭原则，讲的是设计要对扩展有好的支持，而对修改要严格限制。这是最重要也是最为抽象的原则，基本上我们所说的Reusable Software既是基于此原则而开发的。其他的原则也是对它的实现提供了路径。

2) Liskov Substituition Principle（LSP），里氏代换原则，很严格的原则，规则是“子类必须能够替换基类，否则不应当设计为其子类。”也就是说，子类只能去扩展基类，而不是隐藏或覆盖基类。

3) Dependence Inversion Principle（DIP），依赖倒换原则，“设计要依赖于抽象而不是具体化”。换句话说就是设计的时候我们要用抽象来思考，而不是一上来就开始划分我需要哪些哪些类，因为这些是具体。这样做有什么好处呢？人的思维本身实际上就是很抽象的，我们分析问题的时候不是一下子就考虑到细节，而是很抽象的将整个问题都构思出来，所以面向抽象设计是符合人的思维的。另外这个原则会很好的支持OCP，面向抽象的设计使我们能够不必太多依赖于实现，这样扩展就成为了可能，这个原则也是另一篇文章《Design by Contract》的基石。

4) Interface Segregation Principle（ISP），接口隔离原则，“将大的接口打散成多个小接口”，这样做的好处很明显，我不知道有没有必要再继续描述了，为了节省篇幅，实际上我对这些原则只是做了一个小总结，如果有需要更深入了解的话推荐看《Java与模式》，MS MVP的一：本巨作！^_^

5) 单一职责：一个类的功能尽量单一，降低耦合

6) Law of Demeter or Least Knowlegde Principle（LoD or LKP），迪米特法则或最少知识原则，这个原则首次在Demeter系统中得到正式运用，所以定义为迪米特法则。它讲的是“一个对象应当尽可能少的去了解其他对象”。也就是又一个关于如何松耦合（Loosely-Coupled）的法则。