Induction of Design Pattern

网上查到的设计模式有23种,通过归纳去认识他们也是一种不错的视角。
我这边不按照主流的观点去划分为创建型、结构型、行为型三大类,我只归纳为创建型(Creational Class)、简单功能场景(Simple Method Class)、复杂功能场景(Complex Method Class)三大类。原因是结构、行为这种词本身就比较泛,而模式本身就是一种比较交叉融合的状态,所以根据我的理解,我主观性的重新划分,当然只是为了让我理解和思考。

其实程序设计模式里,大多数的考虑初衷都是为了面向未来未知情况,在当前就先规划做好扩展方式,方便能让未来使用者使用方便的代码结构。
也有能节省资源的设计模式、方便解耦的设计模式...

Creational Class

帮助机器(系统)节省资源的创建对象模式:

  • Singleton Pattern
  • Flyweight Pattern
  • Prototype Pattern(也叫克隆模式)

面对未来未知,由外部提供需求来创建对象模式,如下几种应该说在各大框架里能常看到:

  • Simple Factory
  • Factory Methoed Pattern
  • Abstract Factory Pattern
    当抽象工厂模式只生产一个产品时,和工厂方法模式没啥区别。当它生成一组或多个产品时,才有所区别。
  • Buidler Pattern

Simple Method Class

Simple Method Class就是非常好理解的设计模式,他们往往都能对应现实生活中某些机构、某种职业的运作模式,所以非常好理解。

  • Facade Pattern(也叫前台接待模式)
  • Template Pattern
    模版模式也是一种应对未来未知情况的解决方案,部分可知,部分不可知;
  • 观察者模式
    一种一对多的关系,当一个类的状态发送改变,就通知所有依赖(有关系)的类;
  • 状态模式/策略模式
    将状态封装成一个类,不同状态的类,会有不同的行为。 状态模式和策略模式是一样的。
  • 中介者模式
    为了解耦各个类,只通过中介者去通信,有点绕。
  • Proxy Pattern
    • 代理对象充当了客户端和目标对象之间的中介,从而可以在访问目标对象时添加额外的逻辑;
    • 代理对象持有一个真实主题的引用,并在需要时创建或获取真实主题对象;
    • 代理对象在调用真实主题之前或之后,执行一些额外的操作,例如权限验证、缓存、日志记录等。
  • 责任链模式
    责任链模式很容易理解(想想在公司请假的流程,员工发起,组长审批——>部门领导审批——>HR审批——>BOSS...)
    它也用到递归,控制不好就容易死循环;

下面这些个模式一般不在程序设计的时候考虑,并且新程序在设计初期就不应该出现如下情况,会把程序搞复杂!反而,它们更适合运用在程序维护阶段,程序已经运行起来,在不大规模的重构之前,也没有好办法的时候才考虑使用。当然还有一种情况,就是你使用别人写好的接口,调用别人的SDK,你是无法修改调用的接口方法的,你能做的就是自己封装多一层中间层,下面是几种不同场景介绍:

  • Adapter Pattern(适配器模式)
    当需要使用一个已存在的类,但其接口与要求的接口不匹配时。
  • Decorator Pattern(装饰者模式)
    • 用于在不修改现有对象结构的前提下,动态地给对象添加额外的功能;
    • Decorator 和 Proxy有相似的地方,就是都是给现有类.方法增加额外功能,不同点在于Decorator是不修改现有对象结构

Complex Method Class

下面这几个模式就有点绕了,只能自己多思考了,无他法。

  • Composite Pattern
    需要用到递归,控制不好就容易死循环;
  • Bridge Pattern
  • 迭代器模式
    解耦思想,将行为和对象分离;
  • 备忘录模式
    在不暴露对象内部状态的情况下保存和恢复对象的状态。
    为了完成这个保护和恢复功能涉及的类比较多,就容易复杂。
  • 命令模式
    也是一种解构思想,将行为和数据结构分离;
    命令模式还有一个撤销操作,和备忘录有相似;
  • 访问者模式
    • TODO
  • 解释器模式
    • TODO

热门相关:总裁别再玩了   嫡嫁千金   楚氏赘婿   重生之将门毒后   紫府仙缘