设计模式
跟随曾探老师的脚步,用 ES6 语法整理的一份有关设计模式的文档,区别于冗长的文档,每篇文章都可以让你快速的知道此设计模式的模式动机和实现思路及应用场景
19 篇内容
JavaScript 中没有提供关于面向对象中类式的继承,也没有在语言层面提供抽象类和接口的支持。因此,在用设计模式编写代码的时候,必须要跟传统面向对象语言进行区分
单例模式「Singleton Pattern」:指一个类只有一个实例,且该类能自行创建这个实例的一种模式,为了节省内存资源、保证数据内容的一致性。
工厂模式「Factory Pattern」:属于创建者模式,将模块中对象的创建和对象的使用进行分离,外界对于这些对象只需要知道它们的接口,而不需要知道其中具体的实现细节,以此来使整个系统的设计更加符合单一职责的原则。
策略模式「Strategy Pattern」:定义一系列的算法,把它们一个个的封装起来,并且使它们可以互相替换
代理模式「Proxy Pattern」:当客户不方便访问一个对象或不满足需要的时候,提供一个替身对象来控制对这个对象的访问,所以客户实际上访问的是替身对象,替身对象对请求做出一些处理之后,再把请求转交给本体对象
迭代器模式「Iterator Pattern」:是指提供一种方法顺序访问一个聚合对象中的各个元素,而又不需要暴露该对象的内部表示。迭代器模式可以把迭代的过程从业务逻辑中分离出来,在使用迭代器模式之后,即使不关心对象的内部构造,也可以按顺序访问其中的每个元素
订阅-发布模式又叫观察者模式「Observer Pattern」,它定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都将得到通知。在 JavaScript 开发中,我们一般用事件模型 来替代传统的发布—订阅模式。
组合模式「Composite Pattern」:将对象组合成树形结构,以表示「部分-整体」的层次结构。除了用来表示树形结构之外,组合模式的另一个好处是通过对象的多态性表现,使得用户对单个对象和组合对象的使用具有一致性。
命令模式「Command Pattern」:是一种数据驱动的设计模式,它属于行为型模式。 请求以命令的形式包裹在对象中,并传给调用对象。 调用对象寻找可以处理该命令的合适的对象,并把该命令传给相应的对象,该对象执行命令。
模板方法模式「Template Pattern」:是一种只需使用继承就可以实现的非常简单的模式模板方法模式由两部分结构组成,第一部分是抽象父类,第二部分是具体的实现子类。通常在抽象父类中封装了子类的算法框架,包括一些公共方法以及封装子类中所有方法的执行顺序。子类通过继承这个抽象类,也继承了整个算法结构,并且可以选择重写父类的方法。
享元模式「Flyweight Pattern」:是一种用于性能优化的模式。享元模式的核心是运用「共享技术」来有效支持大量细粒度的对象。
责任链模式「Chain of Responsibility Pattern」为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。在这种模式中,通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求,那么它会把相同的请求传给下一个接收者,依此类推。
中介者模式「Mediator Pattern」:用一个中介对象来封装一系列的对象交互,中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。中介者模式又称为调停者模式,它是一种对象行为型模式。
装饰者模式也称为包装模式「Wrapper Pattern」:给对象动态的增加职责的方式称为装饰者模式,装饰者模式能够在不改变对象自身的基础上,在程序运行期间给对象动态地添加职责。跟继承相比,装饰者是一种更轻便灵活的做法,这是一种「即用即付」的方式,比如天冷了就多穿一件外套
状态模式「State Pattern」:允许一个对象在其内部状态改变时改变它的行为,对象看起来似乎修改了它的类。状态模式的关键是区分事物内部的状态,事物内部状态的改变往往会带来事物的行为改变
适配器模式「Adapter Pattern」:将一个接口转换成客户希望的另一个接口,适配器模式使接口不兼容的那些类可以一起工作,其别名为包装器「Wrapper」
单一职原则 SRP「Single responsibility principle」:就一个类而言,应该仅有一个引起它变化的原因。修改代码总是一件危险的事情,特别是当两个职责耦合在一起的时候,一个职责发生变化可能会影响到其他职责的实现,造成意想不到的破坏。因此一个对象(方法)只做一件事情
最少知识原则 LKP「Least Knowledge Principle」说的是一个软件实体应当尽可能少地与其他实体发生相互作用。这里的软件实体是一个广义的概念,不仅包括对象,还包括系统、类、模块、函数、变量等。
开放封闭原则 OCP 「Open Closed Principle」, 它的定义如下,软件实体「类、模块、函数」等应该是可以扩展的,但是不可以修改