设计模式(持续更新)
LanyuanXiaoyao's Blog ヽ(✿゚▽゚)ノ

设计模式(持续更新)


简介

什么是设计模式呢?其实设计模式没有想象中那么高大上,设计模式其实就是以前的程序员大牛们长期编程总结下来的一些经验,也就是我们平常所说的最佳实现,换句话说就是按照这种方式来写我们的代码,会让我们的代码变得更加“优美”。
这里“优美”的定义显然当然不是指我们的字写得漂亮,而是指我们的代码比较合理,更容易更改,更容易适应需求。
我们可以需要一个更加专业一点的描述

在软件工程中,设计模式(design pattern)是对软件设计中普遍存在(反复出现)的各种问题,所提出的解决方案。这个术语是由埃里希·伽玛(Erich Gamma)等人在1990年代从建筑设计领域引入到计算机科学的。
  
设计模式并不直接用来完成代码的编写,而是描述在各种不同情况下,要怎么解决问题的一种方案。面向对象设计模式通常以类别或物件来描述其中的关系和相互作用,但不涉及用来完成应用的特定类别或物件。设计模式能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免会引起麻烦的紧耦合,以增强软件设计面对并适应变化的能力。
  
并非所有的软件模式都是设计模式,设计模式特指软件“设计”层次上的问题。还有其它非设计模式的模式,如架构模式(英语:Architectural pattern)。同时,演算法不能算是一种设计模式,因为演算法主要是用来解决计算上的问题,而非设计上的问题。
—— 维基百科

原则

说到设计模式,我们首先要先说设计模式的6个原则(也有归类为5个原则,其实理解意思就行了,差别不大),这6个原则是我们面向对象设计思想的精髓,设计模式其实就是这6个原则的具体实现和混合使用。

  1. 开闭原则(Open Close Principle)
    开闭原则的意思是:对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。简言之,是为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点。
  2. 里氏代换原则(Liskov Substitution Principle)
    里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。LSP 是继承复用的基石,只有当派生类可以替换掉基类,且软件单位的功能不受到影响时,基类才能真正被复用,而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化,而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。
  3. 依赖倒转原则(Dependence Inversion Principle)
    这个原则是开闭原则的基础,具体内容:针对接口编程,依赖于抽象而不依赖于具体。
  4. 接口隔离原则(Interface Segregation Principle)
    这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。它还有另外一个意思是:降低类之间的耦合度。由此可见,其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想,它强调降低依赖,降低耦合。
  5. 迪米特法则(Demeter Principle)
    又称最少知道原则,最少知道原则是指:一个实体应当尽量少地与其他实体之间发生相互作用,使得系统功能模块相对独立。
  6. 合成复用原则(Composite Reuse Principle)
    合成复用原则是指:尽量使用合成/聚合的方式,而不是使用继承。

分类1

设计模式当然也有分类,这个分类是根据各个模式的功能来区分的,主要有5类2(主要关注前面的3大类):

  1. 创建型模式(9种) 这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式,而不是使用新的运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
    1. 工厂模式(Factory Pattern)
      定义一个接口用于创建对象,但是让子类决定初始化哪个类。工厂方法把一个类的初始化下放到子类。
    2. 抽象工厂模式(Abstract Factory Pattern)
      为一个产品族提供了统一的创建接口。当需要这个产品族的某一系列的时候,可以从抽象工厂中选出相应的系列创建一个具体的工厂类。
    3. 单例模式(Singleton Pattern)
      确保一个类只有一个实例,并提供对该实例的全局访问。
    4. 建造者模式(Builder Pattern)
      将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
    5. 原型模式(Prototype Pattern)
      用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。
    6. 惰性初始模式
    7. 对象池模式
    8. RAII模式
    9. 多例模式
  2. 结构型模式(8种) 这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。
    1. 适配器模式(Adapter Pattern)
      将某个类的接口转换成客户端期望的另一个接口表示。适配器模式可以消除由于接口不匹配所造成的类兼容性问题。
    2. 桥接模式(Bridge Pattern)
      将一个抽象与实现解耦,以便两者可以独立的变化。
    3. 过滤器模式(Filter、Criteria Pattern)
    4. 组合模式(Composite Pattern)
      把多个对象组成树状结构来表示局部与整体,这样用户可以一样的对待单个对象和对象的组合。
    5. 装饰模式(Decorator Pattern)
      向某个对象动态地添加更多的功能。修饰模式是除类继承外另一种扩展功能的方法。
    6. 外观模式(Facade Pattern)
      为子系统中的一组接口提供一个一致的界面, 外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
    7. 享元模式(Flyweight Pattern)
      通过共享以便有效的支持大量小颗粒对象。
    8. 代理模式(Proxy Pattern)
      为其他对象提供一个代理以控制对这个对象的访问。
  3. 行为型模式(13种) 这些设计模式特别关注对象之间的通信。
    1. 责任链模式(Chain of Responsibility Pattern)
      为解除请求的发送者和接收者之间耦合,而使多个对象都有机会处理这个请求。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它。
    2. 命令模式(Command Pattern)
      将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可取消的操作。
    3. 解释器模式(Interpreter Pattern)
      给定一个语言, 定义它的文法的一种表示,并定义一个解释器, 该解释器使用该表示来解释语言中的句子。
    4. 迭代器模式(Iterator Pattern)
      提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
    5. 中介者模式(Mediator Pattern)
      包装了一系列对象相互作用的方式,使得这些对象不必相互明显作用,从而使它们可以松散偶合。当某些对象之间的作用发生改变时,不会立即影响其他的一些对象之间的作用,保证这些作用可以彼此独立的变化。
    6. 备忘录模式(Memento Pattern)
      备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下,将一个对象的状态捉住,并外部化,存储起来,从而可以在将来合适的时候把这个对象还原到存储起来的状态。
    7. 观察者模式(Observer Pattern)
      在对象间定义一个一对多的联系性,由此当一个对象改变了状态,所有其他相关的对象会被通知并且自动刷新。
    8. 状态模式(State Pattern)
      让一个对象在其内部状态改变的时候,其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时,系统便改变所选的子类。
    9. 空对象模式(Null Object Pattern)
      通过提供默认对象来避免空引用。
    10. 策略模式(Strategy Pattern)
      定义一个算法的系列,将其各个分装,并且使他们有交互性。策略模式使得算法在用户使用的时候能独立的改变。
    11. 模板模式(Template Pattern)
      模板方法模式准备一个抽象类,将部分逻辑以具体方法及具体构造子类的形式实现,然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法,从而对剩余的逻辑有不同的实现。先构建一个顶级逻辑框架,而将逻辑的细节留给具体的子类去实现。
    12. 访问者模式(Visitor Pattern)
      封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改,接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统,它把数据结构和作用于结构上的操作之间的耦合解脱开,使得操作集合可以相对自由的演化。
    13. 黑板模式
  4. 并发型模式(11种)
    1. 主动对象
    2. 阻碍
    3. 双重检查锁定
    4. 守卫
    5. 领导者/追随者
    6. 监测对象模式
    7. 读写锁
    8. 调度
    9. 线程池模式
    10. 线程特定存储
    11. 反应器
  5. J2EE模式(8种) 这些设计模式特别关注表示层。这些模式是由 Sun Java Center 鉴定的。
    1. MVC模式(MVC Pattern)
    2. 业务代表模式(Business Delegate Pattern)
    3. 组合实体模式(Composite Entity Pattern)
    4. 数据访问对象模式(Data Access Object Pattern)
    5. 前端控制器模式(Front Controller Pattern)
    6. 拦截过滤器模式(Intercepting Filter Pattern)
    7. 服务定位器模式(Service Locator Pattern)
    8. 传输对象模式(Transfer Object Pattern)

我们主要关注前面3类共25种设计模式,它们的关系可以用一张图来表示:

设计模式之间的关系

思考

这里是关于设计模式的一些说法和思考

不要过度设计

设计模式的本质是一种经验!经验!!经验!!!说三遍!
这种经验是以前的程序员总结下来的一种写代码的套路,但是我们都知道,条条大路通罗马,写出一手可以维护扩展性强的代码远不止一种方式,设计模式只是其中的一种,最忌讳的就是为了设计模式而使用设计模式,既然是经验,那么设计模式的最重要的意义就是用来参考,而不是照抄,当然这不是说即使某个设计模式能完美解决你的需求也不去用它,而是我们要合理地看待设计模式,最忌讳盲目地使用设计模式。
举个例子,设计模式要解决的问题是需求的扩展,如果需求已经非常确定,某些功能是不需要扩展的,那我们为什么还要使用设计模式呢?
正确对待设计模式的方式是了解它,并明确其中的思想,了解为什么这种模式可以解决这种问题,再在我们的实际编码中运用这种思想,不要陷入了过度设计的陷阱。

参考资料

  1. 设计模式简介
  2. 设计模式有何不妥,所谓的荼毒体现在哪?
  3. 设计模式-维基百科

注释

  1. 我们常说的设计模式来源于“四人帮”(Gang of Four,GoF)编写的《设计模式:可复用面向对象软件的基础》(Design Patterns: Elements of Reusable Object-Oriented Software)一书,但我们知道,设计模式作为一种经验和最佳实践,肯定不止这本书中描述的20+种,世界上可以称为设计模式的模式千千万万,所以分类里面也加入了由麦克康奈尔(en:Steve McConnell)编写的《代码大全》(Code Complete)中描述的几种模式,当然还有一些被我们常用却没有被收录在书中的 

  2. 市面上流传的设计模式只有23种,其余补充的模式来源于维基百科和其他一些资料,显然不是每一种奇奇怪怪的模式我们都需要花时间去研究,所以我们只探讨主要的23种加一些我认为值得探讨的模式,不在流行模式里面的已经用斜体标明出来,可自行研究 


评论