PHP

PHP常见设计模式

Posted by silsuer on June 3, 2018

参考链接: http://laravelacademy.org/post/2465.html

创建型

抽象工厂模式

抽象工厂模式为一组相关或相互依赖的对象创建提供接口,而无需指定其具体实现类。抽象工厂的客户端不关心如何创建这些对象,只关心如何将它们组合到一起。

定义一个抽象工厂类(抽象类),类中定义应该实现的抽象方法

根据不同的对象,创建不同的实体工厂类

链接: http://laravelacademy.org/post/2471.html

建造者模式

建造者模式将一个复杂的对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。

定义一个“导演类”(Director),导演类并不知道具体的实现细节,导演类中定义build()方法用来创建对象

build方法中传入不同的Builder对象(建造者),然后根据建造者对象,进行组装每一个部分,最后返回组装好的对象

对于建造者:

  1. 实现一个通用接口(interface),规定(比如车辆对象的建造者)对象的每个部分(添加引擎,添加轮子,添加车门等等)

  2. 用各种实体建造者类去实现这个接口(自行车、汽车等)

  3. 添加一个车辆的抽象类,规定为车辆添加部分的方法

  4. 添加实体车辆类实现车辆,等待建造者的构建

链接: http://laravelacademy.org/post/2489.html

工厂方法模式

定义一个创建对象的接口,但是让子类去实例化具体类。工厂方法模式让类的实例化延迟到子类中。

定义一个抽象工厂方法类(FactoryMethod),类中定义创建新对象的方法create()

定义大类型的工厂去实现这个抽象类(意大利造车场类继承造车场类),switch一下,根据不同的要求,new不同的车辆

链接: http://laravelacademy.org/post/2506.html

多例模式

多例模式和单例模式类似,但可以返回多个实例。比如我们有多个数据库连接,MySQL、SQLite、Postgres,又或者我们有多个日志记录器,分别用于记录调试信息和错误信息,这些都可以使用多例模式实现。

和单例模式相似,都有私有的构造方法,克隆方法,反序列化方法,只是在getInstance()中需要传入参数,根据传入的参数,选择是否实例化新的实例

链接: http://laravelacademy.org/post/2519.html

对象池模式

对象池(也称为资源池)被用来管理对象缓存。对象池是一组已经初始化过且可以直接使用的对象集合,用户在使用对象时可以从对象池中获取对象,对其进行操作处理,并在不需要时归还给对象池而非销毁它。

若对象初始化、实例化的代价高,且需要经常实例化,但每次实例化的数量较少的情况下,使用对象池可以获得显著的性能提升。常见的使用对象池模式的技术包括线程池、数据库连接池、任务队列池、图片资源对象池等。

当然,如果要实例化的对象较小,不需要多少资源开销,就没有必要使用对象池模式了,这非但不会提升性能,反而浪费内存空间,甚至降低性能。

  1. 对象池Pool:

    保存的都是相同的对象,instances属性保存对象数组, class属性保存这个连接池的对象类型(保证连接池空的时候可以new一个出来)

    get()方法从对象数组中取出一个对象,没有的话就new一个出来

    dispose()方法用于归还对象,把传入的对象放入对象数组中

  2. 过程处理类 Processor: 记录连接池的最大连接数,当前正在连接数,等待队列等

  3. 工作者类 Worker: run()方法执行逻辑后,调用传入的回调,比如是过程处理类的处理完成方法

链接: http://laravelacademy.org/post/2532.html

原型模式

通过创建原型使用克隆方法实现对象创建而不是使用标准的 new 方式。

定义抽象的原型类

定义多个继承这个原型类的实体类

根据传入的原型类类型,clone这个类,获得对象

链接: http://laravelacademy.org/post/2546.html

简单工厂模式

简单工厂的作用是实例化对象,而不需要客户了解这个对象属于哪个具体的子类。简单工厂实例化的类具有相同的接口或者基类,在子类比较固定并不需要扩展时,可以使用简单工厂。

在工厂类中定义一个方法,根据传入的类型实例化工厂类(编译阶段就已经确定了所有可实例化类型,添加类型需要修改工厂)

链接:http://laravelacademy.org/post/2643.html

单例模式

简单说来,单例模式的作用就是保证在整个应用程序的生命周期中,任何一个时刻,单例类的实例都只存在一个,同时这个类还必须提供一个访问该类的全局访问点。

常见使用实例:数据库连接器;日志记录器(如果有多种用途使用多例模式);锁定文件。

对象的getInstance()方法中,判断是否存在实例,如果存在,返回这个实例,否则新建,并且重写 __clone,__construct,__wakeup 方法避免外部实例化

链接: http://laravelacademy.org/post/2599.html

静态工厂模式

与简单工厂类似,该模式用于创建一组相关或依赖的对象,不同之处在于静态工厂模式使用一个静态方法来创建所有类型的对象,该静态方法通常是 factory 或 build。

在工厂类中定义一个静态方法,根据传入的类名,判断是否存在这个类,如果存在,实例化后返回

链接: http://laravelacademy.org/post/2647.html

结构型

结构型设计模式用于处理类和对象的组合

适配器模式

首先我们来看看什么是适配器。

适配器的存在,就是为了将已存在的东西(接口)转换成适合我们需要、能被我们所利用的东西。在现实生活中,适配器更多的是作为一个中间层来实现这种转换作用。比如电源适配器,它是用于电流变换(整流)的设备。

适配器模式将一个类的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类可以在一起工作。

在适配器构造函数中传入期望兼容的对象,在不兼容的方法中调用这个期望兼容对象对应的方法(在纸质书的翻页turnPages方法中调用电子书的pressNext方法)

其实就是在适配器类中重写了不兼容的方法,调用可以使用的方法,达到兼容的效果

链接: http://laravelacademy.org/post/2660.html

桥梁模式

系统设计中,总是充满了各种变数,这是防不慎防的。比如客户代表可能要求修改某个需求,增加某种功能等等。面对这样那样的变动,你只能去不停的修改设计和代码,并且要开始新的一轮测试……

那采取什么样的方式可以较好的解决变化带给系统的影响?你可以分析变化的种类,将不变的框架使用抽象类定义出来,然后再将变化的内容使用具体的子类来分别实现。这样面向客户的只是一个抽象类,这种方式可以较好的避免为抽象类中现有接口添加新的实现所带来的影响,缩小了变化带来的影响。但是这可能会造成子类数量的爆炸,并且在某些时候不是很灵活。

但是当你各个子类的行为经常发生变化,或者有一定的重复和组合关系时,我们不妨将这些行为提取出来,也采用接口的方式提供出来,然后以组合的方式将服务提供给原来的子类。这样就达到了前端和被使用的后端独立的变化,而且还达到了后端的重用。

其实这就是桥梁模式的诞生。

桥梁模式(Bridge)也叫做桥接模式,用于将抽象和实现解耦,使得两者可以独立地变化。

桥梁模式完全是为了解决继承的缺点而提出的设计模式。在该模式下,实现可以不受抽象的约束,不用再绑定在一个固定的抽象层次上。

以汽车为例: 分为生产和组装两个过程,那么定义一个抽象生产类,摩托实体类继承这个抽象类,汽车实体类继承这个类,在实体类中进行生成和组装的过程

把生产和组装抽成一个接口,均为work方法,并使用生产类和组装类实现这个接口,那么在实体类中,调用生产work和组装work即可

链接: http://laravelacademy.org/post/2680.html

组合模式

组合模式(Composite Pattern)有时候又叫做部分-整体模式,用于将对象组合成树形结构以表示“部分-整体”的层次关系。组合模式使得用户对单个对象和组合对象的使用具有一致性。

常见使用场景:如树形菜单、文件夹菜单、部门组织架构图等。

例如:

  1. 定义一个抽象的表单元素类

  2. 所有表单元素都继承这个类

  3. 使用的时候通过将多个表单元素组合起来,得到最终的表单结果

数据映射模式

在了解数据映射模式之前,先了解下数据映射,它是在持久化数据存储层(通常是关系型数据库)和驻于内存的数据表现层之间进行双向数据传输的数据访问层。

数据映射模式的目的是让持久化数据存储层、驻于内存的数据表现层、以及数据映射本身三者相互独立、互不依赖。这个数据访问层由一个或多个映射器(或者数据访问对象)组成,用于实现数据传输。通用的数据访问层可以处理不同的实体类型,而专用的则处理一个或几个。

数据映射模式的核心在于它的数据模型遵循单一职责原则(Single Responsibility Principle), 这也是和 Active Record 模式的不同之处。最典型的数据映射模式例子就是数据库 ORM 模型 (Object Relational Mapper)。

准确来说该模式是个架构模式。

就像laravel的模型一样,使用User->属性来给对象赋值,最后使用User->save()将对象数据保存到数据库中,保证数据库和内存中对象的实体映射关系

链接: http://laravelacademy.org/post/2739.html

装饰模式

装饰器模式能够从一个对象的外部动态地给对象添加功能。

通常给对象添加功能,要么直接修改对象添加相应的功能,要么派生对应的子类来扩展,抑或是使用对象组合的方式。显然,直接修改对应的类这种方式并不可取。在面向对象的设计中,我们也应该尽量使用对象组合,而不是对象继承来扩展和复用功能。装饰器模式就是基于对象组合的方式,可以很灵活的给对象添加所需要的功能。装饰器模式的本质就是动态组合。动态是手段,组合才是目的。

常见的使用示例:Web服务层 —— 为 REST 服务提供 JSON 和 XML 装饰器。

将一个大对象由多个小对象组合起来,

定义一个抽象组件类,所有小对象都实现这个类

定义多个实体类,实现抽象组件类,各自完成各自的功能

定义一个装饰器抽象类,维持一个指向组件对象的接口对象,并定义一个和组件接口一致的接口

实现装饰器抽象类,在其中使用注入的组件前后添加要做的操作

使用时将原始对象传入装饰器实体类中,实现透明的给对象增加功能

http://laravelacademy.org/post/2760.html

依赖注入模式

依赖注入(Dependency Injection)是控制反转(Inversion of Control)的一种实现方式。

我们先来看看什么是控制反转。

当调用者需要被调用者的协助时,在传统的程序设计过程中,通常由调用者来创建被调用者的实例,但在这里,创建被调用者的工作不再由调用者来完成,而是将被调用者的创建移到调用者的外部,从而反转被调用者的创建,消除了调用者对被调用者创建的控制,因此称为控制反转。

要实现控制反转,通常的解决方案是将创建被调用者实例的工作交由 IoC 容器来完成,然后在调用者中注入被调用者(通过构造器/方法注入实现),这样我们就实现了调用者与被调用者的解耦,该过程被称为依赖注入。

依赖注入不是目的,它是一系列工具和手段,最终的目的是帮助我们开发出松散耦合(loose coupled)、可维护、可测试的代码和程序。这条原则的做法是大家熟知的面向接口,或者说是面向抽象编程。

依赖注入模式需要在调用者外部完成容器创建以及容器中接口与实现类的运行时绑定工作,在 Laravel 中该容器就是服务容器,而接口与实现类的运行时绑定则在服务提供者中完成。此外,除了在调用者的构造函数中进行依赖注入外,还可以通过在调用者的方法中进行依赖注入。

其实就是原本在调用者类中实例化的对象,通过构造函数,从外部作为一个参数传入,成为调用者对象中的一个属性

http://laravelacademy.org/post/2792.html

门面模式

门面模式(Facade)又称外观模式,用于为子系统中的一组接口提供一个一致的界面。门面模式定义了一个高层接口,这个接口使得子系统更加容易使用:引入门面角色之后,用户只需要直接与门面角色交互,用户与子系统之间的复杂关系由门面角色来实现,从而降低了系统的耦合度。

门面模式对客户屏蔽子系统组件,因而减少了客户处理的对象的数目并使得子系统使用起来更加方便;实现了子系统与客户之间的松耦合关系,而子系统内部的功能组件往往是紧耦合的,松耦合关系使得子系统的组件变化不会影响到它的客户;如果应用需要,门面模式并不限制客户程序使用子系统类,因此你可以让客户程序在系统易用性和通用性之间加以选择。

Laravel 中门面模式的使用也很广泛,基本上每个服务容器中注册的服务提供者类都对应一个门面类。

http://laravelacademy.org/post/2807.html

流接口模式

在软件工程中,流接口(Fluent Interface)是指实现一种面向对象的、能提高代码可读性的 API 的方法,其目的就是可以编写具有自然语言一样可读性的代码,我们对这种代码编写方式还有一个通俗的称呼 —— 方法链。

Laravel 中流接口模式有着广泛使用,比如查询构建器,邮件等等。

其实就是return $this 使其支持连贯操作

http://laravelacademy.org/post/2828.html

代理模式

代理模式(Proxy)为其他对象提供一种代理以控制对这个对象的访问。使用代理模式创建代理对象,让代理对象控制目标对象的访问(目标对象可以是远程的对象、创建开销大的对象或需要安全控制的对象),并且可以在不改变目标对象的情况下添加一些额外的功能。

在某些情况下,一个客户不想或者不能直接引用另一个对象,而代理对象可以在客户端和目标对象之间起到中介的作用,并且可以通过代理对象去掉客户不能看到的内容和服务或者添加客户需要的额外服务。

经典例子就是网络代理,你想访问 Facebook 或者 Twitter ,如何绕过 GFW?找个代理网站.

代理模式在很多情况下都非常有用,特别是你想强行控制一个对象的时候,比如延迟加载、监视状态变更的方法等等。

与类似接口的区别:

适配器模式 —— 适配器模式为它所适配的对象提供了一个不同的接口,而代理提供了与它的实体相同的接口。

装饰器模式 —— 两者目的不同:装饰器为对象添加一个或多个功能,而代理则控制对对象的访问。

http://laravelacademy.org/post/2841.html

注册模式

注册模式(Registry)也叫做注册树模式,注册器模式。注册模式为应用中经常使用的对象创建一个中央存储器来存放这些对象 —— 通常通过一个只包含静态方法的抽象类来实现(或者通过单例模式)。

定义一个抽象类,在其中定义set和get方法,可以存入和取出对象

http://laravelacademy.org/post/2850.html

行为型

行为型设计模式用于处理类的对象间通信:

责任链模式

责任链模式将处理请求的对象连成一条链,沿着这条链传递该请求,直到有一个对象处理请求为止,这使得多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系。

责任链模式在现实中使用的很多,常见的就是 OA 系统中的工作流。

责任链模式的主要优点在于可以降低系统的耦合度,简化对象的相互连接,同时增强给对象指派职责的灵活性,增加新的请求处理类也很方便;其主要缺点在于不能保证请求一定被接收,且对于比较长的职责链,请求的处理可能涉及到多个处理对象,系统性能将受到一定影响,而且在进行代码调试时不太方便。

就是将处理请求的对象通过一个链对象连成一条链,然后在每个对象中写处理请求的逻辑,到最后返回处理成功或者失败

http://laravelacademy.org/post/2858.html

命令模式

命令模式(Command)将请求封装成对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤消的操作。这么说很抽象,我们举个例子:

假设我们有一个调用者类 Invoker 和一个接收调用请求的类 Receiver,在两者之间我们使用命令类 Command 的 execute 方法来托管请求调用方法,这样,调用者 Invoker 只知道调用命令类的 execute 方法来处理客户端请求,从而实现接收者 Receiver 与调用者 Invoker 的解耦。

Laravel 中的 Artisan 命令就使用了命令模式。

命令模式就是将一组对象的相似行为,进行了抽象,将调用者与被调用者之间进行解耦,提高了应用的灵活性。命令模式将调用的目标对象的一些异构性给封装起来,通过统一的方式来为调用者提供服务。

http://laravelacademy.org/post/2871.html

迭代器模式

迭代器模式(Iterator),又叫做游标(Cursor)模式。提供一种方法访问一个容器(Container)对象中各个元素,而又不需暴露该对象的内部细节。

当你需要访问一个聚合对象,而且不管这些对象是什么都需要遍历的时候,就应该考虑使用迭代器模式。另外,当需要对聚集有多种方式遍历时,可以考虑去使用迭代器模式。迭代器模式为遍历不同的聚集结构提供如开始、下一个、是否结束、当前哪一项等统一的接口。

PHP标准库(SPL)中提供了迭代器接口 Iterator,要实现迭代器模式,实现该接口即可。

PHP中使用的地方不多,一般定义自己的数据类型的时候需要使用

http://laravelacademy.org/post/2882.html

中介者模式

中介者模式(Mediator)就是用一个中介对象来封装一系列的对象交互,中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。

对于中介对象而言,所有相互交互的对象,都视为同事类,中介对象就是用来维护各个同事对象之间的关系,所有的同事类都只和中介对象交互,也就是说,中介对象是需要知道所有的同事对象的。当一个同事对象自身发生变化时,它是不知道会对其他同事对象产生什么影响,它只需要通知中介对象,“我发生变化了”,中介对象会去和其他同事对象进行交互的。这样一来,同事对象之间的依赖就没有了。有了中介者之后,所有的交互都封装在了中介对象里面,各个对象只需要关心自己能做什么就行,不需要再关心做了之后会对其他对象产生什么影响,也就是无需再维护这些关系了。

中介者主要是通过中介对象来封装对象之间的关系,使之各个对象在不需要知道其他对象的具体信息情况下通过中介者对象来与之通信。同时通过引用中介者对象来减少系统对象之间关系,提高了对象的可复用和系统的可扩展性。但是就是因为中介者对象封装了对象之间的关联关系,导致中介者对象变得比较庞大,所承担的责任也比较多。它需要知道每个对象和他们之间的交互细节,如果它出问题,将会导致整个系统都会出问题。

http://laravelacademy.org/post/2894.html

备忘录模式

备忘录模式又叫做快照模式(Snapshot)或 Token 模式,备忘录模式的用意是在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,这样就可以在合适的时候将该对象恢复到原先保存的状态。

我们在编程的时候,经常需要保存对象的中间状态,当需要的时候,可以恢复到这个状态。比如,我们使用Eclipse进行编程时,假如编写失误(例如不小心误删除了几行代码),我们希望返回删除前的状态,便可以使用Ctrl+Z来进行返回。这时我们便可以使用备忘录模式来实现。

备忘录模式所涉及的角色有三个:备忘录(Memento)角色、发起人(Originator)角色、负责人(Caretaker)角色。

这三个角色的职责分别是:

发起人:记录当前时刻的内部状态,负责定义哪些属于备份范围的状态,负责创建和恢复备忘录数据。

备忘录:负责存储发起人对象的内部状态,在需要的时候提供发起人需要的内部状态。

管理角色:对备忘录进行管理,保存和提供备忘录。

就是对数据进行保存以及回滚的操作,在备忘录中保存历史记录,通过发起人对管理角色的操作,将当前状态恢复到备忘录中的某个状态

http://laravelacademy.org/post/2903.html

空对象模式

空对象模式并不是 GoF 那本《设计模式》中提到的 23 种经典设计模式之一,但却是一个经常出现以致我们不能忽略的模式。该模式有以下优点:

简化客户端代码 减少空指针异常风险 更少的条件控制语句以减少测试用例 在空对象模式中,以前返回对象或 null 的方法现在返回对象或空对象 NullObject,这样会减少代码中的条件判断,比如之前调用返回对象方法要这么写:

if (!is_null($obj)) { $obj->callSomething(); }

现在因为即使对象为空也会返回空对象,所以可以直接这样调用返回对象上的方法:

$obj->callSomething();

从而消除客户端的检查代码。

当然,你可能已经意识到了,要实现这种调用的前提是返回对象和空对象需要实现同一个接口,具备一致的代码结构.

http://laravelacademy.org/post/2912.html

观察者模式

观察者模式有时也被称作发布/订阅模式,该模式用于为对象实现发布/订阅功能:一旦主体对象状态发生改变,与之关联的观察者对象会收到通知,并进行相应操作。

将一个系统分割成一个一些类相互协作的类有一个不好的副作用,那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合,这样会给维护、扩展和重用都带来不便。观察者就是解决这类的耦合关系的。

消息队列系统、事件都使用了观察者模式。

PHP 为观察者模式定义了两个接口:SplSubject 和 SplObserver。SplSubject 可以看做主体对象的抽象,SplObserver 可以看做观察者对象的抽象,要实现观察者模式,只需让主体对象实现 SplSubject ,观察者对象实现 SplObserver,并实现相应方法即可。

观察者模式解除了主体和具体观察者的耦合,让耦合的双方都依赖于抽象,而不是依赖具体。从而使得各自的变化都不会影响另一边的变化

主体对象和观察者对象各自实现接口,然后主题对象的每一个变化,都会触发观察者对象的update方法,接收变化后的主题对象。

http://laravelacademy.org/post/2935.html

规格模式

规格模式(Specification)可以认为是组合模式的一种扩展。有时项目中某些条件决定了业务逻辑,这些条件就可以抽离出来以某种关系(与、或、非)进行组合,从而灵活地对业务逻辑进行定制。另外,在查询、过滤等应用场合中,通过预定义多个条件,然后使用这些条件的组合来处理查询或过滤,而不是使用逻辑判断语句来处理,可以简化整个实现逻辑。

这里的每个条件就是一个规格,多个规格/条件通过串联的方式以某种逻辑关系形成一个组合式的规格

http://laravelacademy.org/post/2960.html

状态模式

状态模式(State)又称状态对象模式,主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。状态模式允许一个对象在其内部状态改变的时候改变其行为,把状态的判断逻辑转移到表示不同的一系列类当中,从而把复杂的逻辑判断简单化。

用一句话来表述,状态模式把所研究的对象的行为包装在不同的状态对象里,每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候,其行为也随之改变。

在软件开发过程中,应用程序可能会根据不同的情况作出不同的处理。最直接的解决方案是将这些所有可能发生的情况全都考虑到。然后使用if… ellse语句来做状态判断来进行不同情况的处理。但是对复杂状态的判断就显得“力不从心了”。随着增加新的状态或者修改一个状体(if else(或switch case)语句的增多或者修改)可能会引起很大的修改,而程序的可读性,扩展性也会变得很弱。维护也会很麻烦。那么就要考虑使用状态模式。

状态模式的主要优点在于封装了转换规则,并枚举可能的状态,它将所有与某个状态有关的行为放到一个类中,并且可以方便地增加新的状态,只需要改变对象状态即可改变对象的行为,还可以让多个环境对象共享一个状态对象,从而减少系统中对象的个数;其缺点在于使用状态模式会增加系统类和对象的个数,且状态模式的结构与实现都较为复杂,如果使用不当将导致程序结构和代码的混乱,对于可以切换状态的状态模式不满足“开闭原则”的要求。

把传统方式的if else 变为 switch判断状态,然后把具体逻辑放到一个一个的对象中去处理

http://laravelacademy.org/post/2971.html

策略模式

在软件开发中也常常遇到类似的情况,实现某一个功能有多种算法或者策略,我们可以根据环境或者条件的不同选择不同的算法或者策略来完成该功能。如查找、排序等,一种常用的方法是硬编码(Hard Coding)在一个类中,如需要提供多种查找算法,可以将这些算法写到一个类中,在该类中提供多个方法,每一个方法对应一个具体的查找算法;当然也可以将这些查找算法封装在一个统一的方法中,通过if…else…或者case等条件判断语句来进行选择。这两种实现方法我们都可以称之为硬编码,如果需要增加一种新的查找算法,需要修改封装算法类的源代码;更换查找算法,也需要修改客户端调用代码。在这个算法类中封装了大量查找算法,该类代码将较复杂,维护较为困难。如果我们将这些策略包含在客户端,这种做法更不可取,将导致客户端程序庞大而且难以维护,如果存在大量可供选择的算法时问题将变得更加严重。

如何让算法和对象分开来,使得算法可以独立于使用它的客户而变化?为此我们引入策略模式。

策略模式(Strategy),又叫算法簇模式,就是定义了不同的算法族,并且之间可以互相替换,此模式让算法的变化独立于使用算法的客户。

常见的使用场景比如对象筛选,可以根据日期筛选,也可以根据 ID 筛选;又比如在单元测试中,我们可以在文件和内存存储之间进行切换。

在创建对象的外部,传入不同的筛选策略,得到不同的筛选结果

http://laravelacademy.org/post/2990.html

模版方法模式

模板方法模式又叫模板模式,该模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。

模板方法模式将主要的方法定义为 final,防止子类修改算法骨架,将子类必须实现的方法定义为 abstract。而普通的方法(无 final 或 abstract 修饰)则称之为钩子(hook)。

模板方法模式是基于继承的代码复用技术,模板方法模式的结构和用法也是面向对象设计的核心之一。在模板方法模式中,可以将相同的代码放在父类中,而将不同的方法实现放在不同的子类中。

在模板方法模式中,我们需要准备一个抽象类,将部分逻辑以具体方法以及具体构造函数的形式实现,然后声明一些抽象方法来让子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法,从而对剩余的逻辑有不同的实现,这就是模板方法模式的用意。模板方法模式体现了面向对象的诸多重要思想,是一种使用频率较高的模式

就是在模版类中,将可以被修改的方法设置为抽象方法,不能修改的设置为final方法,子类必须实现修改方法,这样就实现了不同的子类,部分逻辑不同。

http://laravelacademy.org/post/3006.html

访问者模式

我们去银行柜台办业务,一般情况下会开几个个人业务柜台的,你去其中任何一个柜台办理都是可以的。我们的访问者模式可以很好付诸在这个场景中:对于银行柜台来说,他们是不用变化的,就是说今天和明天提供个人业务的柜台是不需要有变化的。而我们作为访问者,今天来银行可能是取消费流水,明天来银行可能是去办理手机银行业务,这些是我们访问者的操作,一直是在变化的。

访问者模式就是表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

访问者模式适用于数据结构相对稳定的系统,它把数据结构和作用于结构之上的操作之间的耦合解脱开,使得操作集合可以相对自由的演化。在本例中,User、Group 是数据结构,而 RolePrintVisitor 是访问者(用于结构之上的操作)。

当实现访问者模式时,要将尽可能多的将对象浏览逻辑放在 Visitor 类中,而不是放在它的子类中,这样的话,ConcreteVisitor 类所访问的对象结构依赖较少,从而使维护较为容易。

http://laravelacademy.org/post/3024.html

其他设计模式

委托模式

委托是对一个类的功能进行扩展和复用的方法。它的做法是:写一个附加的类提供附加的功能,并使用原来的类的实例提供原有的功能。

假设我们有一个 TeamLead 类,将其既定任务委托给一个关联辅助对象 JuniorDeveloper 来完成:本来 TeamLead 处理 writeCode 方法,Usage 调用 TeamLead 的该方法,但现在 TeamLead 将 writeCode 的实现委托给 JuniorDeveloper 的 writeBadCode 来实现,但 Usage 并没有感知在执行 writeBadCode 方法。

就是在构造函数中传入一个委托类,执行类的执行函数,调用委托类的执行函数去做(初级开发者干活,leader喝咖啡….)

http://laravelacademy.org/post/3038.html

服务定位器模式

当系统中的组件需要调用某一服务来完成特定的任务时,通常最简单的做法是使用 new 关键字来创建该服务的实例,或者通过工厂模式来解耦该组件与服务的具体实现部分,以便通过配置信息等更为灵活的方式获得该服务的实例。然而,这些做法都有着各自的弊端:

  • 在组件中直接维护对服务实例的引用,会造成组件与服务之间的关联依赖,当需要替换服务的具体实现时,不得不修改组件中调用服务的部分并重新编译解决方案;即使采用工厂模式来根据配置信息动态地获得服务的实例,也无法针对不同的服务类型向组件提供一个管理服务实例的中心位置;

  • 由于组件与服务之间的这种关联依赖,使得项目的开发过程受到约束。在实际项目中,开发过程往往是并行的,但又不是完全同步的,比如组件的开发跟其所需要的服务的开发同时进行,但很有可能当组件需要调用服务时,服务却还没完成开发和单体测试。遇到这种问题时,通常会将组件调用服务的部分暂时空缺,待到服务完成开发和单体测试之后,将其集成到组件的代码中。但这种做法不仅费时,而且增大了出错的风险;

  • 针对组件的单体测试变得复杂。每当对组件进行单体测试时,不得不为其配置并运行所需要的服务,而无法使用Service Stub来解决组件与服务之间的依赖;

  • 在组件中可能存在多个地方需要引用服务的实例,在这种情况下,直接创建服务实例的代码会散布到整个程序中,造成一段程序存在多个副本,大大增加维护和排错成本;

  • 当组件需要调用多个服务时,不同服务初始化各自实例的方式又可能存在差异。开发人员不得不了解所有服务初始化的API,以便在程序中能够正确地使用这些服务;

  • 某些服务的初始化过程需要耗费大量资源,因此多次重复地初始化服务会大大增加系统的资源占用和性能损耗。程序中需要有一个管理服务初始化过程的机制,在统一初始化接口的同时,还需要为程序提供部分缓存功能。

要解决以上问题,我们可以在应用程序中引入服务定位器(Service Locator)模式。

服务定位器(Service Locator)模式是一种企业级应用程序体系结构模式,它能够为应用程序中服务的创建和初始化提供一个中心位置,并解决了上文中所提到的各种设计和开发问题。

服务定位器模式和依赖注入模式都是控制反转(IoC)模式的实现。我们在服务定位器中注册给定接口的服务实例,然后通过接口获取服务并在应用代码中使用而不需要关心其具体实现。我们可以在启动时配置并注入服务提供者。

如果你了解 Laravel 框架,你对这一流程会很熟悉,没错,这就是 Laravel 框架的核心机制,我们在服务提供者中绑定接口及其实现,将服务实例注册到服务容器中,然后在使用时可以通过依赖注入或者通过服务接口/别名获取服务实例的方式调用服务。

在一个服务定位器中添加各种服务(类),需要的时候从定位器中取出

http://laravelacademy.org/post/2820.html

资源库模式

Repository 是一个独立的层,介于领域层与数据映射层(数据访问层)之间。它的存在让领域层感觉不到数据访问层的存在,它提供一个类似集合的接口提供给领域层进行领域对象的访问。Repository 是仓库管理员,领域层需要什么东西只需告诉仓库管理员,由仓库管理员把东西拿给它,并不需要知道东西实际放在哪。

Repository 模式是架构模式,在设计架构时,才有参考价值。应用 Repository 模式所带来的好处,远高于实现这个模式所增加的代码。只要项目分层,都应当使用这个模式。

和数据映射模式有些像,不过它是把数据映射出来的数据又重新组装成了对象,然后对于控制器中的操作,调用数据映射层中的方法。

http://laravelacademy.org/post/3053.html