最近老是听人提起设计模式,之前在做java的时候也常听老师傅提起设计模式。
那设计模式到底是个什么?前端开发需不需要用到设计模式呢?怎么用呢?
像java这样成熟的语言,自然而然会积累一些优秀的实践,java开发会在设计时自然而然的遵守某些约定
比如开关原则,单一职责,依赖倒置,里氏替换,接口隔离等等
这些感觉像是后台开发才会用到的东西,我们写前端代码能借鉴吗?
随着接触node,写node后台代码的需求越来越多,就越发觉得设计模式的重要性
接口如何设计?性能如何优化?如何对node代码进行分层?分层要遵循什么样的规则?
如何设计健壮的node接口?如何保证node服务的稳定性?类要怎么定义?
以上就是我遇到的问题,所以我会花一些时间来搞明白。如果你也有这方面的疑惑,不如加入进来一起学习。

写在前面:
学习类的文章需要查很多资料,总结成自己能理解的方式记录下来,方便以后复习。
另外学习笔记类文章不允许转载,只作为本人的学习记录。如果您认为本文侵犯了您的权益,请您告知作者来修改。
本文所有定义概念来自于 刘伟老师-《设计模式的艺术》,书中通过简单的文字说明模式的原理,值得一读。原文链接:http://blog.csdn.net/lovelion/article/details/17517213
本文部分demo来自于菜鸟教程,是搜寻一圈下来感觉代码最干净最直观的网站。网站地址:http://www.runoob.com/design-pattern/design-pattern-tutorial.html
以上的博文网站大都是用java来实现示例,我只能去通读一遍后将自己的理解用javascript写出来,如果示例存在错误,请邮件通知作者修改:xiaoqiang@isjs.cn

一.什么是设计模式?

设计模式(Design pattern)是开发人员在开发过程中对问题不断总结从而形成的解决方案。
设计模式来源于建筑学,对所有解决同一问题儿设计的建筑结构中,找出其中高质量设计的相似性。
这部分相似性就被称为模式语言。你也可以称设计模式为最佳解决方案或最佳实践。
一句话总结:模式是在特定环境下人们解决某类重复出现问题的一套成功或有效的解决方案

二.设计模式与软件框架?

软件框架是解决某个问题领域内的一整套软件组织,设计模式是针对软件框架内某一软件生命周期中出现的问题进行解决。
软件框架更实质化一些,设计模式则比较抽象。设计模式本质是逻辑概念,可以应用于任何应用程序。

三.设计原则:

(一) 开关原则 (OCP) Open-Closed Principie
概述:开闭原则是面向对象设计的目标。一个软件实体应该对扩展开发,对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。开关原则要求尽量通过扩展软件实体的方法来适应变化,而不是通过修改已有代码。

(二)里氏替换原则 (LSP) Liskov Substitution Principle
概述:所有引用基类(父类)的地方必须能透明地使用其子类的对象。里氏替换原则要求保证在程序中将基类对象替换成他的子类对象,程序将不会产生任何错误和异常。里氏替换原则是实现开闭原则的重要方式之一,当需要进行扩展时,避免出现多个相同意义的基类对象,而是应该通过扩展基类的子类,运行时再去确定其子类。

(三)依赖倒置原则 (DIP) Dependency Inversion Principle
概述:依赖倒置原则是面向对象设计的主要实现机制之一,主张抽象不应该依赖于细节,细节应当依赖于抽象。换言之,要针对接口编程,而不是针对实现编程。依赖倒置原则的目的是简化系统扩展的复杂度。通过将所有声明,常量提取到最顶层,扩展时只增加实现层和修改顶层配置即可完成,避免了修改原有系统源代码。

大多数情况下,上面介绍的3个设计原则会同时出现,开闭原则是目标,里氏代换原则是基础,依赖倒转原则是手段,他们相辅相成,相互补充,目标一致,只是分析问题时所站角度不同而已。

(四) 单一职责原则 (SRP) Single Responsibility Principle
概述:单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小。定义:一个类只负责一个功能领域中的相应职责。或者可以定义为:就一个类而言,应该只有一个引起它变化的原因。
单一职责原则是实现高内聚、低耦合的指导方针。需要开发人员对类的职责进行划分,将不同的职责封装在不同的类中,将不同的变化原因封装在不同的类中。

(五) 接口隔离原则 (ISP) Interface Segregation Principle
概述:使用多个专门的接口,而不使用单一的总接口,即客户端不应该依赖那些它不需要的接口。尽可能让你的接口更单纯,职责更单一,而不是把所有逻辑糅合到一起。对已有的大接口,需要根据其职责不同分别拆分成不同的小接口。同样适用于其他场景,项目结构,服务结构等,应避免过大过复杂。

(六) 合成复用原则 (CRP) Composite Reuse Principle
概述:尽量使用对象组合而不是继承来达到复用的目的。在面向对象设计中,如果需要复用已有的设计和实现,常常会想到继承。继承会有局限性,不同基类在共享继承属性时增加了类与类之间的耦合,增加了系统维护难度及系统复杂度。另一种复用方式是组合/聚合,组合/聚合可以使系统更灵活,降低类与类之间的耦合度。所以有复用场景时,应先考虑组合聚合关系(关联关系)少使用继承。

(七) 迪米特法则 (LOD) Law Of Demeter
概述:一个软件实体应当尽可能少地与其他实体发生相互作用。一个一个系统符合迪米特法则,那么当其中某一个模块发生修改时,就会尽量少地影响其他模块,扩展会相对容易。迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特会降低系统的耦合度,使类与类之间保持松散的耦合关系。实际应用中要注意:1.在类的划分上,尽量创建松耦合类 2.在设计类的结构时,应当尽量降低其成员变量和成员函数的访问权限,尽量限制动态类型的产生。3.要将一个对象对其他对象的引用降到最低。

四.创建型模式(Creational Pattern)

说明:创建型模式关注对象的创建过程,是最常用的设计模式,创建型模式将对象的创建和使用分离,在使用时无需关心对象的创建细节,从而降低系统的耦合度,让设计方案易于修改和扩展。

  1. 单例模式(Singleton Pattern)
  2. 简单工厂模式(Simple Factory Pattern)
  3. 工厂模式(Factory Method Pattern)
  4. 抽象工厂模式(Abstract Factory Pattern)
  5. 原型模式(Prototype Pattern)
  6. 建造者模式(Builder Pattern)

五.结构型模式(Structural Pattern)

说明:结构型模式关注如何将现有类或对象组织在一起形成更强大的结构。不同的结构模式从不同角度来组合类或对象。

  1. 适配器模式(Adaoter Pattern)
  2. 桥接模式(Bridge Pattern)
  3. 组合模式(Composite Pattern)
  4. 装饰模式(Decorator Pattern)
  5. 外观模式(Facade Pattern)
  6. 享元模式(Flyweight Pattern)
  7. 代理模式(Proxy Pattern)

六.行为型模式(Behavioral Pattern)

说明:行为型模式关注系统中对象之间的交互,研究系统在运行时对象之间的相互通信与写作,进一步明确对象的职责。行为型模式重点关注类和对象之间的相互作用和职责划分。

  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. 策略模式(Strategy Pattern)
  10. 模板方法模式(Template Method Pattern)
  11. 访问者模式(Visitor Pattern)