Christopher Alexander 说过:“每个模式描述了一个在咱们周围不断重复发生的问题,以及该问题的解决方案的核心。这样,你就能一次又一次地使用该方案而没必要作重复劳动”。简单来讲就是:算法
设计模式(Design Pattern)是一套被反复使用、多数人知晓的、通过分类编目的、代码设计经验的总结,使用设计模式是为了可重用代码、让代码更容易被他人理解而且保证代码可靠性。
设计模式开发的规范,最优的方案,选择合适的模式可大大提升开发效率,少走弯路。若是将设计模式比喻成“三十六计”,那么每个模式都是一种计策,它为解决某一类问题而诞生,设计模式能很好的解决一些问题。设计模式
经典应用框架中常见的设计模式分为三类:框架
常见的建立型模式有:Factory 工厂模式
;Singleton 单例模式
;Prototype 原型模式
学习
常见的结构型模式有:Adapter 适配器模式
;Decorator 装饰器模式
;Proxy 代理模式
spa
常见的行为型模式有:Strategy 策略模式
;Template 模板模式
;Delegate 委派模式
;Observer 观察者模式
设计
注意:在经常使用的23种设计模式中其实面没有委派模式(Delegate)的影子,可是在Spring中委派模式确实用的比较多的一种模式,Spring MVC框架中的DispatcherServlet其实就用到了委派模式。代理
单例模式:Singleton的做用是保证在应用程序中,一个类Class只有一个实例存在。并提供全局访问。Singleton限制了实例个数,有利于GC的回收。code
策略模式:策略模式针对一组算法,将每个算法封装到具备共同接口的独立的类中,从而使得它们能够相互替换。策略模式使得算法能够在不影响到客户端的状况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类,各类算法在具体的策略类中提供。因为算法和环境独立开来,算法的增减,修改都不会影响到环境和客户端。视频
原型模式:经过给出一个原型对象来指明所要建立的对象的类型,而后用复制这个原型对象的方法建立出更多同类型的对象。原始模型模式容许动态的增长或减小产品类,产品类不须要非得有任何事先肯定的等级结构,原始模型模式适用于任何的等级结构。缺点是每个类都必须配备一个克隆方法server
由于Java中的提供clone()方法来实现对象的克隆,因此Prototype模式实现一会儿变得很简单。
工厂模式:定义一个用于建立对象的接口,让接口子类经过工厂方法决定实例化哪个类。
装饰模式:装饰模式以对客户端透明的方式扩展对象的功能,是继承关系的一个替代方案,提供比继承更多的灵活性。动态给一个对象增长功能,这些功能能够再动态的撤消。增长由一些基本功能的排列组合而产生的很是大量的功能。
使用Decorator的理由是:这些功能须要由用户动态决定加入的方式和时机。Decorator提供了"即插即用"的方法,在运行期间决定什么时候增长何种功能。
适配器模式:把一个类的接口变换成客户端所期待的另外一种接口,从而使本来因接口缘由不匹配而没法一块儿工做的两个类可以一块儿工做。适配类能够根据参数返还一个合适的实例给客户端
将两个不兼容的类纠合在一块儿使用,属于结构型模式,须要Adaptee(被适配者)和Adaptor(适配器)两个身份。
为什么使用?
咱们常常碰到要将两个没有关系的类组合在一块儿使用,第一解决方案是:修改各自类的接口,可是若是咱们没有源代码,或者,咱们不肯意为了一个应用而修改各自的接口。 怎么办? 使用Adapter,在这两种接口之间建立一个混合接口(混血儿)。
如何使用?
实现Adapter方式,其实"think in Java"的"类再生"一节中已经提到,有两种方式:组合(composition)和继承(inheritance)。
代理模式:代理模式给某一个对象提供一个代理对象,并由代理对象控制对源对象的引用。代理就是一我的或一个机构表明另外一我的或者一个机构采起行动。
某些状况下,客户不想或者不可以直接引用一个对象,代理对象能够在客户和目标对象直接起到中介的做用。客户端分辨不出代理主题对象与真实主题对象。代理模式能够并不知道真正的被代理对象,而仅仅持有一个被代理对象的接口,这时候代理对象不可以建立被代理对象,被代理对象必须有系统的其余角色代为建立并传入。
观察者模式:观察者模式定义了一种一队多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时,会通知全部观察者对象,使他们可以自动更新本身。发布订阅。
模板模式:模板方法模式准备一个抽象类,将部分逻辑以具体方法以及具体构造子的形式实现,而后声明一些抽象方法来迫使子类实现剩余的逻辑。
不一样的子类能够以不一样的方式实现这些抽象方法,从而对剩余的逻辑有不一样的实现。先制定一个顶级逻辑框架,而将逻辑的细节留给具体的子类去实现。
设计上的事就是这样,想到了, 就能比较优雅的解决问题,想不到的话, 就只能使用处处修改代码的方法比较笨拙的应对问题,还容易将项目弄的混乱。固然也建议大家看看这套关于设计模式视频,放在君羊895244712里面,或许会给大家一些启发。
如今我比较庆幸当初学习了设计模式,而没有听其余人的“建议”:咱们作的项目中用不到设计模式,学这个没用。设计模式是个好东西,之后确定还要进一步的学习,而且在项目中多实践,提高本身的设计能力。
其实设计模式并不难,难的是真正领悟它的精妙,而且能灵活的运用于平常项目的开发。