设计模式

设计模式

设计模式分为23种,这里我们只写2种

单例模式

目的:让一个类只能生成一个对象

//将构造函数做成私有的
//在类里面做一个函数造对象
//在方法里面加限制条件
class Ren{
    public static $r;
    public $name;
    private function __construct(){
          
    }
    
    public static function duixiang(){     //做成静态可以直接调用方法
            if(empty(Ren::$r)){      //判断是否为空  Ren可以换成self
           Ren::$r =  new Ren();   
        }
       return Ren::$r;      //返回第一个对象的值
    }
}

$r = Ren::duixiang();
$r->name = "张三";
$r1 = Ren::duixiang();
var_dump($r1);     //结果与$r相同

 

工厂模式

目的:做一个专门造对象的工厂

class Suan(){          //先做一个父类
    public $a;
    public $b;
    public function yunsuan(){
    }
}

class Jia extends Suan(){    //做一个加法的子类
    public function yunsuan(){
       return $this->a+$this->b;
    }
}

class Jian extends Suan(){    //做一个减法的子类
    public function yunsuan(){
       return $this->a-$this->b;
    }
}

class cheng extends Suan(){    //做一个乘法的子类
    public function yunsuan(){
       return $this->a*$this->b;
    }
}

class chu extends Suan(){    //做一个除法的子类
    public function yunsuan(){
       return $this->a/$this->b;
    }
}

$j = new Jia();
$j->a = 10;
$j->b = 5;
echo $j->yunsuan();

 

问题:如果每个扩展者的函数命名方式不一致,则上述方法就存在问题

 

class GongChang(){      //专门用来生产对象
    public static function duixiang($ysf){       //给一个运算符返回一个对象
             switch($ysf){
              case "+":
                   return new Jia();
                   break;
              case "-":
                   return new Jian();
                   break;
              case "*":
                   return new cheng();
                   break;
              case "/":
                   return new chu();
                   break;
               }
    }
}
//不需要知道方法的名称是什么就可以使用
$j = GongChang::duixiang("+");

 

书籍推荐:大话设计模式

 

面向对象(OOP)的设计原则

 

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)的法则。

posted @ 2018-02-15 00:17  桃花灬仙人  阅读(116)  评论(0编辑  收藏  举报