设计模式
单例模式
介绍
确保每一个类只有一个实例,并且自行实例化并向整个系统提供这个实例。这个类称为单例类,提供全局 访问方法。
特点:
- 单例类只能有一个实例。
- 单例类必须自己创建自己的唯一实例。
- 单例类必须给所有其他对象提供这个实例。
UML
说明
单例模式包含如下角色:
Singleton:单例
应用场景
在计算机系统中,线程池、缓存、日志对象、对话框、打印机、显卡的驱动程序对象常被设计成单例。这些应用都或多或少具有资源管理器的功能。每台计算机可以有若干个打印机,但只能有一个Printer Spooler,以避免两个打印作业同时输出到打印机中;每台计算机可以有若干通信端口,系统应当集中管理这些通信端口,以避免一个通信端口同时被两个请求同时调用。总之,选择单例模式就是为了避免不一致状态。
分类
- 饿汉式(创建类的实例时就创建对象)
优点:没有加锁。线程安全。执行效率高。
缺点:类加载时就初始化,浪费内存。资源利用效率不高,可能调用类的其他静态方法加载了该类,但是getInstance()方法永远没有被执行到。 - 懒汉式 (需要时才创建对象)
优点:避免没有用到的时候创建实例,资源利用率高。
缺点:非线程安全,需要加锁,第一次加载不够快。
- 非线程安全:
如果有两个线程同时调用getInstance()方法,则会创建两个实例化对象。所以是非线程安全的。
public class Singleton {
private static Singleton ourInstance;
public static Singleton getInstance() {
if (null == ourInstance) {
ourInstance = new Singleton();
}
return ourInstance;
}
private Singleton() {
}
}
- 线程安全:给方法加锁
如果有多个线程调用getInstance()方法,当一个线程获取该方法,而其它线程必须等待,消耗资源。
public class Singleton {
private static Singleton ourInstance;
public synchronized static Singleton getInstance() {
if (null == ourInstance) {
ourInstance = new Singleton();
}
return ourInstance;
}
private Singleton() {
}
}
- 线程安全:双重检查锁(同步代码块)
第一次检查是确保之前是一个空对象,而非空对象就不需要同步了,空对象的线程然后进入同步代码块,如果不加第二次空对象检查,两个线程同时获取同步代码块,一个线程进入同步代码块,另一个线程就会等待,而这两个线程就会创建两个实例化对象,所以需要在线程进入同步代码块后再次进行空对象检查,才能确保只创建一个实例化对象。
public class Singleton {
private static Singleton ourInstance;
public synchronized static Singleton getInstance() {
if (null == ourInstance) {
synchronized (Singleton.class) {
if (null == ourInstance) {
ourInstance = new Singleton();
}
}
}
return ourInstance;
}
private Singleton() {
}
}
- 线程安全:静态内部类
利用静态内部类,谋个线程在调用该方法时会创建一个实例化对象。
public class Singleton {
private static class SingletonHodler {
private static Singleton ourInstance = new Singleton();
}
public synchronized static Singleton getInstance() {
return SingletonHodler.ourInstance;
}
private Singleton() {
}
}
- 线程安全:枚举
不仅能避免多线程同步问题,而且还能防止反序列化重新创建新的对象,但是在枚举中的其他任何方法的线程安全由程序员自己负责。还有防止上面的通过反射机制调用私用构造器。
enum SingletonTest {
INSTANCE;
public void whateverMethod() {
}
}
示例
<?php
class Singleton{
//私有属性,用于保存实例
private static $instance;
//构造方法私有化,防止外部创建实例
private function __construct(){}
//公有属性,用于测试
public $a;
//公有方法,用于获取实例
public static function getInstance(){
//判断实例有无创建,没有的话创建实例并返回,有的话直接返回
if(!(self::$instance instanceof self)){
self::$instance = new self();
}
return self::$instance;
}
//克隆方法私有化,防止复制实例
private function __clone(){}
}
三个要点:
- 需要一个保存类的唯一实例的静态成员变量。
- 构造函数和克隆函数必须声明为私有的,防止外部程序new类从而失去单例模式的意义。
- 必须提供一个访问这个实例的公共的静态方法(通常为getInstance方法),从而返回唯一实例的一个引用 。
优缺点
优点:
- 提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例,所以它可以严格控制客户怎样以及何时访问它,并为设计及开发团队提供了共享的概念。
- 由于在系统内存中只存在一个对象,因此可以节约系统资源,对于一些需要频繁创建和销毁的对象,单例模式无疑可以提高系统的性能。
- 允许可变数目的实例。我们可以基于单例模式进行扩展,使用与单例控制相似的方法来获得指定个数的对象实例。
缺点:
- 由于单例模式中没有抽象层,因此单例类的扩展有很大的困难。
- 单例类的职责过重,在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角色,提供了工厂方法,同时又充当了产品角色,包含一些业务方法,将产品的创建和产品的本身的功能融合到一起。
- 滥用单例将带来一些负面问题,如为了节省资源将数据库连接池对象设计为单例类,可能会导致共享连接池对象的程序过多而出现连接池溢出;现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术,因此,如果实例化的对象长时间不被利用,系统会认为它是垃圾,会自动销毁并回收资源,下次利用时又将重新实例化,这将导致对象状态的丢失。
工厂模式
简单工厂模式
介绍
简单工厂模式又称为静态工厂方法(Static Factory Method)模式,它属于类创建型模式。在简单工厂模式中,可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。
UML
说明
CashFactory类:负责创建具体产品的实例
CashSuper类:抽象产品类,定义产品子类的公共接口
CreateCashAccept 类:具体产品类,实现Product父类的接口功能,也可添加自定义的功能
实例
<?php
//简单工厂模式
class Cat
{
function __construct()
{
echo "I am Cat class <br>";
}
}
class Dog
{
function __construct()
{
echo "I am Dog class <br>";
}
}
class Factory
{
public static function CreateAnimal($name){
if ($name == 'cat') {
return new Cat();
} elseif ($name == 'dog') {
return new Dog();
}
}
}
$cat = Factory::CreateAnimal('cat');
$dog = Factory::CreateAnimal('dog');
优缺点
最大的优点在于实现对象的创建和对象的使用分离,将对象的创建交给专门的工厂类负责。最大的缺点在于工厂类不够灵活,增加新的具体产品需要修改工厂类的判断逻辑代码,而且产品较多时,工厂方法代码将会非常复杂。
工厂方法模式
介绍
工厂方法模式通过定义一个抽象的核心工厂类,并定义创建产品对象的接口,创建具体产品实例的工作延迟到其工厂子类去完成。这样做的好处是核心类只关注工厂类的接口定义,而具体的产品实例交给具体的工厂子类去创建。当系统需要新增一个产品是,无需修改现有系统代码,只需要添加一个具体产品类和其对应的工厂子类,使系统的扩展性变得很好,符合面向对象编程的开闭原则。
UML
说明
Product:抽象产品类
ConcreteProduct:具体产品类
Factory:抽象工厂类
ConcreteFactory:具体工厂类
实例
<?php
interface Animal{
public function run();
public function say();
}
class Cat implements Animal
{
public function run(){
echo "I ran slowly <br>";
}
public function say(){
echo "I am Cat class <br>";
}
}
class Dog implements Animal
{
public function run(){
echo "I'm running fast <br>";
}
public function say(){
echo "I am Dog class <br>";
}
}
abstract class Factory{
abstract static function createAnimal();
}
class CatFactory extends Factory
{
public static function createAnimal()
{
return new Cat();
}
}
class DogFactory extends Factory
{
public static function createAnimal()
{
return new Dog();
}
}
$cat = CatFactory::createAnimal();
$cat->say();
$cat->run();
$dog = DogFactory::createAnimal();
$dog->say();
$dog->run();
优缺点
工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了面向对象的多态性,工厂方法模式保持了简单工厂模式的优点,而且克服了它的缺点。在工厂方法模式中,核心的工厂类不再负责所有产品的创建,而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口,而不负责产品类被实例化这种细节,这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。
抽象工厂模式
介绍
抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们具体的类。抽象工厂模式又称为Kit模式,属于对象创建型模式。
此模式是对工厂方法模式的进一步扩展。在工厂方法模式中,一个具体的工厂负责生产一类具体的产品,即一对一的关系,但是,如果需要一个具体的工厂生产多种产品对象,那么就需要用到抽象工厂模式了。
UML
示例
<?php
interface TV{
public function open();
public function use();
}
class HaierTv implements TV
{
public function open()
{
echo "Open Haier TV <br>";
}
public function use()
{
echo "I'm watching TV <br>";
}
}
interface PC{
public function work();
public function play();
}
class LenovoPc implements PC
{
public function work()
{
echo "I'm working on a Lenovo computer <br>";
}
public function play()
{
echo "Lenovo computers can be used to play games <br>";
}
}
abstract class Factory{
abstract public static function createPc();
abstract public static function createTv();
}
class ProductFactory extends Factory
{
public static function createTV()
{
return new HaierTv();
}
public static function createPc()
{
return new LenovoPc();
}
}
$newTv = ProductFactory::createTV();
$newTv->open();
$newTv->use();
$newPc = ProductFactory::createPc();
$newPc->work();
$newPc->play();
建造者模式
介绍
建造者模式又名生成器模式,是一种对象构建模式。它可以将复杂对象的建造过程抽象出来(抽象类别),使这个抽象过程的不同实现方法可以构造出不同表现(属性)的对象。
建造者模式是一步一步创建一个复杂的对象,它允许用户只通过指定复杂对象的类型和内容就可以构建它们,用户不需要知道内部的具体构建细节。例如,一辆汽车由轮子,发动机以及其他零件组成,对于普通人而言,我们使用的只是一辆完整的车,这时,我们需要加入一个构造者,让他帮我们把这些组件按序组装成为一辆完整的车。
UML
说明
Builder:抽象构造者类,为创建一个Product对象的各个部件指定抽象接口。
ConcreteBuilder:具体构造者类,实现Builder的接口以构造和装配该产品的各个部件。定义并明确它所创建的表示。提供一个检索产品的接口
Director:指挥者,构造一个使用Builder接口的对象。
Product:表示被构造的复杂对象。ConcreateBuilder创建该产品的内部表示并定义它的装配过程。
包含定义组成部件的类,包括将这些部件装配成最终产品的接口。
示例
<?php
/**
* chouxiang builer
*/
abstract class Builder
{
protected $car;
abstract public function buildPartA();
abstract public function buildPartB();
abstract public function buildPartC();
abstract public function getResult();
}
class CarBuilder extends Builder
{
function __construct()
{
$this->car = new Car();
}
public function buildPartA(){
$this->car->setPartA('发动机');
}
public function buildPartB(){
$this->car->setPartB('轮子');
}
public function buildPartC(){
$this->car->setPartC('其他零件');
}
public function getResult(){
return $this->car;
}
}
class Car
{
protected $partA;
protected $partB;
protected $partC;
public function setPartA($str){
$this->partA = $str;
}
public function setPartB($str){
$this->partB = $str;
}
public function setPartC($str){
$this->partC = $str;
}
public function show()
{
echo "这辆车由:".$this->partA.','.$this->partB.',和'.$this->partC.'组成';
}
}
class Director
{
public $myBuilder;
public function startBuild()
{
$this->myBuilder->buildPartA();
$this->myBuilder->buildPartB();
$this->myBuilder->buildPartC();
return $this->myBuilder->getResult();
}
public function setBuilder(Builder $builder)
{
$this->myBuilder = $builder;
}
}
$carBuilder = new CarBuilder();
$director = new Director();
$director->setBuilder($carBuilder);
$newCar = $director->startBuild();
$newCar->show();
?>
策略模式
介绍
策略模式定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。
UML
说明
抽象策略角色: 策略类,通常由一个接口或者抽象类实现。
具体策略角色:包装了相关的算法和行为。
环境角色:持有一个策略类的引用,最终给客户端调用。
应用场景
- 多个类只区别在表现行为不同,可以使用Strategy模式,在运行时动态选择具体要执行的行为。
- 需要在不同情况下使用不同的策略(算法),或者策略还可能在未来用其它方式来实现。
- 对客户隐藏具体策略(算法)的实现细节,彼此完全独立。
示例
<?php
header("Content-type:text/html;Charset=utf-8");
//抽象策略接口
abstract class Strategy{
abstract function wayToSchool();
}
//具体策略角色
class BikeStrategy extends Strategy{
function wayToSchool(){
echo "骑自行车去上学";
}
}
class BusStrategy extends Strategy{
function wayToSchool(){
echo "乘公共汽车去上学";
}
}
class TaxiStrategy extends Strategy{
function wayToSchool(){
echo "骑出租车去上学";
}
}
//环境角色
class Context{
private $strategy;
//获取具体策略
function getStrategy($strategyName){
try{
$strategyReflection = new ReflectionClass($strategyName);
$this->strategy = $strategyReflection->newInstance();
}catch(ReflectionException $e){
$this->strategy = "";
}
}
function goToSchool(){
$this->strategy->wayToSchool();
// var_dump($this->strategy);
}
}
//测试
$context = new Context();
$context->getStrategy("BusStrategy");
$context->goToSchool();
?>
优缺点
- 策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族。恰当使用继承可以把公共的代码转移到父类里面,从而避免重复的代码。
- 策略模式提供了可以替换继承关系的办法。继承可以处理多种算法或行为。如果不是用策略模式,那么使用算法或行为的环境类就可能会有一些子类,每一个子类提供一个不同的算法或行为。但是,这样一来算法或行为的使用者就和算法或行为本身混在一起。决定使用哪一种算法或采取哪一种行为的逻辑就和算法或行为的逻辑混合在一起,从而不可能再独立演化。继承使得动态改变算法或行为变得不可能。
- 使用策略模式可以避免使用多重条件转移语句。多重转移语句不易维护,它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起,统统列在一个多重转移语句里面,比使用继承的办法还要原始和落后。
观察者模式
介绍
定义对象间一对多的依赖关系,使得当前对象改变了状态,所有依赖它的对象都会得到通知并自动更新。
UML
说明
Subject:抽象主题,也就是被观察者(Observable),把所有的观察者对象的引用保存在一个集合里。每个主题都可以有任意数量的观察者,抽象主题提供一个接口,可以增加和删除观察者对象。
ConcreteSubject:具体主题,该角色将有关状态存入具体观察者对象,在具体主题内部状态发生改变时,会给所有注册过的观察者发出通知notify。
Observer:抽象观察者,它定义了更新接口,使得在得到被观察者都更改通知时更新自己。
ConcreteObserver:具体观察者,实现了抽象观察者所定义的更新接口。
应用场景
- 一个抽象模型有两个方面,其中一个方面依赖于另一个方面;(比如:View依赖于Model的数据,当数据发生改变时,更新View)
- 一个对象的改变将导致一个或多个其他对象也发生改变;(比如:同一个数据源对多个观察对象)
- 需要在系统创建一个触发链。(比如A影响B,B影响C)
示例
<?php
abstract class Subject
{
private $observers = [];
public function attach(Observer $observer)
{
array_push($this->observers, $observer);
}
public function detatch($observer)
{
foreach ($this->observers as $key => $value) {
if ($observer === $value) {
unset($this->observers[$key]);
}
}
}
public function notify()
{
foreach ($this->observers as $observer) {
$observer->update();
}
}
}
abstract class Observer
{
abstract function update();
}
class ConcreteSubject extends Subject
{
private $subjectState;
public function setState($state)
{
$this->subjectState = $state;
}
public function getState()
{
return $this->subjectState;
}
}
class ConcreteObserver extends Observer
{
private $name;
private $subject;
function __construct(ConcreteSubject $subject, $name)
{
$this->subject = $subject;
$this->name = $name;
}
public function update()
{
echo "观察者 ".$this->name."的新状态是:".$this->subject->getState()."\n";
}
}
$s = new ConcreteSubject();
$s->attach(new ConcreteObserver($s, "x"));
$s->attach(new ConcreteObserver($s, "y"));
$z = new ConcreteObserver($s, "z");
$s->attach($z);
$s->detatch($z);
$s->setState('ABC');
$s->notify();
优缺点
观察者和被观察者之间是抽象耦合,观察者和被观察者的扩展比较方便。建立一套触发机制。例如建立一条触发链。多个观察者、多级触发等情况下,因为在Java默认是顺序执行,所以一个观察者卡壳,会影响整体的执行效率,这时候推荐考虑采用异步的方式。
参考
https://blog.csdn.net/album_gyd/article/details/81369154
https://segmentfault.com/a/1190000018447091#item-2
https://www.jianshu.com/p/29ac07985af9