设计模式(Design Pattern)表明了最佳的实践,在面向对象的编程中被不少老鸟们反复使用。使用设计模式有不少好处:git
毫无疑问,设计模式于己、于人、于系统都是多赢的。《设计模式》之于程序员,就比如《圣经》之于耶稣信徒同样,意义可想而知!程序员
| 版权声明:一去、二三里,未经博主容许不得转载。github
谈及设计模式,必然离不开 GoF:web
GoF:Gang of Four,也称为“四人组”,即:EErich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人。算法
1994 年,这几位大牛合著出版了一本名为《Design Patterns: Elements of Reusable Object-Oriented Software》(即:《设计模式》)的书。该书首次提到了软件开发中设计模式的概念,将设计模式提高到理论高度,并将之规范化。书中说起了 23 种基本设计模式,时至今日,在可复用面向对象软件的发展过程当中,新的设计模式仍然不断出现。编程
这就是传说中的“风尘四侠”,比起国外的其余技术大咖(不修边幅),看起来要好不少~O(∩_∩)O~。设计模式
根据《设计模式》参考书,共有 23 种设计模式,这些模式能够分为三类:ide
类型 | 描述 |
---|---|
建立型模式(Creational Patterns) | 用于构建对象,以便它们能够从实现系统中分离出来。 |
结构型模式(Structural Patterns) | 用于在许多不一样的对象之间造成大型对象结构。 |
行为型模式(Behavioral Patterns) | 用于管理对象之间的算法、关系和职责。 |
单例模式(Singleton Pattern)
保证一个类仅有一个实例,并提供一个访问它的全局访问点。 svg
抽象工厂模式 (Abstract Factory Pattern)
提供一个建立一系列相关或相互依赖对象的接口,而无需指定它们具体的类。学习
建造者模式(Builder Pattern)
将一个复杂对象的构建与它的表示分离,使得一样的构建过程能够建立不一样的表示。
工厂方法模式 (Factory Method Pattern)
定义一个用于建立对象的接口,让子类决定将哪个类实例化。Factory Method 使一个类的实例化延迟到其子类。
原型模式(Prototype Pattern)
用原型实例指定建立对象的种类,而且经过拷贝这个原型来建立新的对象。
适配器模式(Adapter Pattern)
将一个类的接口转换成客户但愿的另一个接口。Adapter 模式使得本来因为接口不兼容而不能一块儿工做的那些类能够一块儿工做。
桥接模式(Bridge Pattern)
将抽象部分与它的实现部分分离,使它们均可以独立地变化。
装饰者模式(Decorator Pattern)
动态地给一个对象添加一些额外的职责。就扩展功能而言,它比生成子类方式更为灵活。
组合模式(Composite Pattern)
将对象组合成树形结构以表示“部分-总体”的层次结构。它使得客户对单个对象和复合对象的使用具备一致性。
外观模式(Facade Pattern)
为子系统中的一组接口提供一个一致的界面,Facade 模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
享元模式(Flyweight Pattern)
运用共享技术有效地支持大量细粒度的对象。
代理模式(Proxy Pattern)
为其余对象提供一个代理以控制对这个对象的访问。
模版方法模式 (Template Method Pattern)
定义一个操做中的算法的骨架,而将一些步骤延迟到子类中。Template Method 使得子类能够不改变一个算法的结构便可重定义该算法的某些特定步骤。
命令模式(Command Pattern)
将一个请求封装为一个对象,从而使你可用不一样的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可取消的操做。
迭代器模式(Iterator Pattern)
提供一种方法顺序访问一个聚合对象中各个元素,而又不需暴露该对象的内部表示。
观察者模式(Observer Pattern)
定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,全部依赖于它的对象都获得通知并自动刷新。
中介者模式(Mediator Pattern)
用一个中介对象来封装一系列的对象交互。中介者使各对象不须要显式地相互引用,从而使其耦合松散,并且能够独立地改变它们之间的交互。
备忘录模式 (Memento Pattern)
在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象以外保存这个状态。这样之后就可将该对象恢复到保存的状态。
解释器模式(Interpreter Pattern)
给定一个语言,定义它的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的句子。
状态模式(State Pattern)
容许一个对象在其内部状态改变时改变它的行为。对象看起来彷佛修改了它所属的类。
策略模式(Strategy Pattern)
定义一系列的算法,把它们一个个封装起来,而且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户端。
职责链模式 (Chain of Responsibility Pattern)
为解除请求的发送者和接收者之间耦合,而使多个对象都有机会处理这个请求。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它。
访问者模式 (Visitor Pattern)
表示一个做用于某对象结构中的各元素的操做。它使你能够在不改变各元素的类的前提下定义做用于这些元素的新操做。
GoF 中提出的设计模式,至今仍被人津津乐道,你了解多少呢?
第一种:“虽然不懂大家在说什么,貌似很厉害的样子”。大牛才会用到的东西,高端而又神秘!
最后一种:“已上天,正和太阳肩并肩”。心中不曾想用设计模式,写出的代码却到处都是。
假若你和我同样,属于其余状况。。。那么,就认真学习吧!
设计模式能带给你什么?
从“猿猴 -> 程序猿 ”的巨变,怎么样,是否是很炫酷?
有些人说设计模式没用,真是这样吗?
引用一句哲学名言:存在即合理。固然,若要扯非 OO 语言,也许真没什么用!但能够确定的是,非 OO 语言彻底能够借鉴 OO 的思想,设计模式也不例外!
设计模式有多重要?
要作一位大神或所谓的高手,基本之一就是要懂得若干设计模式。设计模式是软件工程的基石脉络,如同大厦的结构同样,你说有多重要?
怎么学习设计模式?
设计模式不是基于理论发明的,而是先有问题场景,再基于需求和情景不断演化设计方案,最后把一些方案标准化成“模式”。
因此,经过实际案例学习是最好的!在讨论每个设计模式时,要尽可能用生活中的真实问题来理解和分析。而后尝试一步步地阐述设计,并以一个能匹配某些模式的设计收尾。
经过先分析问题,而后阐述解决方案,最后获得一个设计模式,这样就不用死记那些图形和定义了!
如何选择设计模式?
设计模式是针对某种情景下某种问题的某种解决方案,也就是说,每一个模式都有本身的使用场景、使用方法和使用后果。正所谓物有两极,各模式也存在相应的优缺点,得其优,而避其劣,终得之!
为何要写设计模式?
虽然设计模式被不少人念叨并不断书写,但笔者仍是决定追随前人的脚步。我很喜欢一句话:“你会了不表明你真的会,要是你能让别人也会,你才是正的会了”!
要真正领悟设计模式的精髓,须要有大量实践经验的积累,这每每是一个漫长的过程。
博客中涉及的全部设计模式都基于实际案例,通过反复打磨。。。为了使其更加生动、形象,每一个模式都有相应的故事化讲解。
相关源码均在笔者的 GitHub 中能够找到,所有通过验证。
持续更新中……