设计模式之粗见
时间飞逝，转眼已快到五月，有段日子没写点东西了，无奈最近确实工作繁忙，连上个厕所都的憋到肾严重抗议才动动，没办法，谁让哥是个责任心强的人呢，半成品的东西可不敢拿出手，不能坏了规矩哈，哥还得在道上混呢。废话少叙，今天写点关于自己的对设计模式的理解，结合日常code中的体会，浅谈一下，咳，又要贻笑大方咯……
说到“高内聚低耦合”，这个只要搞软件的码农，谁都能说上几句，甚至老到点的市场人员也能讲的头头是道，毕竟，高内聚低耦合是我们设计的宗旨和追求的目标嘛。作为一个党员，我还有另一个宗旨就是“全心全力为人民服务”。
有了宗旨，还得有原则，作为一个党员，要牢记四项基本原则：“必须坚持社会主义道路”……作为一个码农，在高内聚低耦合的宗旨下我们也有五项基本原则，即单一职责原则、开放闭合原则、子类可替换原则、接口隔离原则、依赖倒置原则。
·单一职责：一个类应该只有一个单一职责或功能，如果你的类有多于一个原因会导致它变化（或者多于一个职责），你需要依据它们的职责把这个类拆分为多个类。
·开放闭合：（软件实体，如类、模块、函数等等）应当对扩展开放，对修改闭合,这要求抽象方法的时候要恰当。
·子类可替换：子类型必须能够替换它们基类型，这就要求抽象的基类型必须适当，保证子类都能恰当的继承。
·接口隔离：客户端不应该被迫依赖于它们不用的接口，要求每个接口或抽象类型定义的职责明确单一，以方便扩展及继承。
·依赖倒置：也就是Martin说的控制反转，即高层模块不应该依赖底层模块，两者都应该依赖其抽象，这也是针对接口编程的核心，Spring的核心概念之一。
我靠，讲了半天怎么还没到设计模式？不用担心，当你看到这里的时候，其实你对设计模式已经掌握了一大半了。因为所谓的设计模式，就是在遵守这些原则的前提下，大家在一些特定的场景都会采用的类似的解决套路。而大师们把这些套路提出来，安上不同的名字，于是就出现了设计模式。由此可见，世上本没有设计模式，自从有了GOF四人帮，于是开始苦逼……
关于设计模式，一般指的是GOF在他们的那本“黑书”里描述的那23种。那本书个人翻了几页，无奈实在与大师相差巨大。最后贱贱的找了本“Head First”，结合代码学学，也算略知皮毛。根据我的理解一般分为以下几种场景（大场景里包含小场景）。PS：为照顾到有些非技术人员的代码恐惧症，不给出具体示例代码，网上随处可见。
（一）如果你正想new 对象
1、如果你只想要一个对象，那么用singleton单例模式，通过将构造函数private，并提供静态的getInstance方法，需要注意的是此方法需要考虑多线程下的实例问题，可以考虑使用双重检查及加锁机制，保障多线程下的单一性。
2、如果你想要固定数量的对象，那么用 FlyWeight享元模式，说白了就是对象池，初始化的时候创建一些，用的时候从池子里借一个对象，用完归还。
3、如果你不想用new Object()的方式创建一个对象，可以试着用Prototype原型模式克隆一下，记得注意下深克隆和浅克隆的区别。
4、如果你需要根据传入的参数判断具体new的对象，那么用工厂模式，在方法中具体做判断来生产某个具体实例。而所谓的抽象工厂，无非是抽象工厂类有多个方法可以返回不同接口的不同对象。
5、如果你要new的对象有很多可选的参数需要在创建的时候传入，但是这些参数又都是灵活多变自由可选的，那么你需要Builder模式。先创建一个内部静态Builder辅助类，将这些参数由构造器参数转变为普通javabean参数，Builder类中的build方法将设置的参数（如果未设置取默认参数，则使用Builder中默认的参数）一一对应到要创建的对象属性，然后返回该对象，实现创建过程。
（二）如果你正想向外界提供一套公用的接口，而不让外界知道具体如何实现或你想自由的改变实现而不影响外界调用
1、如果你是通过继承来使类提供的对外接口一致，那么用Adapter适配器模式。利用装适配器类适配目标类或接口的子类，它将传入的功能对象改造成适配的目标类或接口，按照目标类所定义的方法，内部调用传入对象的方法或空方法（即传入对象无对应的方法可调）。如果这种适配是用在树形结构中以便于统一处理叶子和非叶子对象，那么这种适配就叫组合模式，如果是用于统一遍历对象，那么就叫Iterator迭代器模式。
2、如果你是通过组合而非继承方式来提供一致性，必定会有多个对象之间相互调用的情况。为避免对象间的紧耦合，你可以用Mediator中介者模式引入一个中介对象，各对象只和中介对象关联。为了提供便捷性，你还可以用外观模式将一个或多个对象的几个方法组合起来。
3、如果你更进一步，想把这种实现设计的都可以动态设置，那么你可以用Strategy策略模式。
4、如果你还要进一步，想把实现完全委托给调用的人，那么你可以用Vistor访问者模式。此模式通过accept一些visitor对象，并将自己(this)当成参数传给visitor的visit方法，实现操作委派。
（三）如果你想包装一些类，在中间提供一些自己的操作
1、如果你只是想增加一些修改的处理并往下调用，那么用Decorator装饰器模式。
2、如果当前实例能够处理完成，可以不再往下调用，也可以对传入的链进行判断以确定是自己处理还是传递到下一个链处理。那么用Chain of Responsibility责任链模式。
（四）如果你想监听一些数据的变化并做相应处理
你可以用Observer观察者模式，定义一个公共的接口，该接口的实现具体类实例化时需要持有数据source实例的引用，并在适当的时机加入到Collections中成为观察者或退出不观察，source实例通过iterator遍历这些实例，调用接口中定义的方法实现通知。
（五）如果你还想了解其他的设计模式
那么你应该找本书好好学学了……
还有其他设计模式，就不一一分类了，先总结这么多，有机会再来，还是那句：“技术在于总结和分享”。
