【推荐给初中级程序员】怎样才能轻松快速的理解好设计模式
以下如果我有说错的或者不到位的地方，请大牛们指出来，不要让我误人子弟奥！大家一起来交流学习！
博文前言 ----和大家唠叨唠叨，不要烦奥
最近发现关于设计模式这一块，大家关注度挺高的。没错，其实我也觉得设计模式是区分程序员与架构师的重要标准，可以说设计模式是架构是必须掌握的基础。但是，对于我们普普通通的程序员来说，即使我们不会去写底层的代码，设计底层框架，但是如果我们深刻的理解了这些常用的设计模式，以后开发项目，如果遇到某些复杂需求，我们不妨这些角度想一想问题，说不定很快会找到思路，而且，现在很多公司都用自己的框架，如果我们理解了，再去研究公司自己的框架，会很轻松的。最近，忙于找工作，闲余时我看了本《设计模式精解》的书，又从网上学习了一下，体会很深，在这里，我想给大家分享一下。
关于设计模式的理解-----先看这个，理解是什么东西再看下面
说到设计模式，字面意思就是项目设计的模式，我第一次看，头也大，感觉什么也看不懂，不是我现有能力看的东西。其实，你应该这样理解，设计模式并不是那么让人害怕的。这就是那些牛人经过无数次的开发，无数次的需求变化然后不断的进行的代码重构（封装等）,慢慢的总结出来的，然后，他觉得不错，给大家分享后，慢慢的很多人遇到这种需求都尝试采用他的这种解决思路，而后，这种固定的解决思路便被人成为一种模式。其实，当我们在和客户交流过程中，会发现客户的需求总是不完整的，有时候可能也是错误的，需求不会说明全部的情况，面对这样的问题，我们就会想能不能通过接口、抽象类等实现一种通用的解决方式，能够根据需求的变化，不会触动底层的东西，只要修改或者添加少量的代码就能解决问题，而且修改的代码量越少越好，当然，这正好符合人们常说的“高内聚，低耦合”的原则。
常用的几种设计模式的理解-------这是重头戏啊！只是个人看法，理解了才能用，理解万岁！
抽象工厂模式
需求问题：为特定的客户需求或者情况提供特定系列的接口实现（类似工厂针对某类需求新建部门）
意图：一系列的对象需要被实例化
效果：该模式将使用哪些对象与如何使用这些对象的逻辑想隔离
实现：定义一个抽象类来指定哪些对象要被创建，然后为每个对象具体实现
单例模式
需求问题：不同的客户对象需要引用同一个对象，你必须确保自己拥有的这个对象有且只有一个
意图：你需要只创建和使用唯一的一个对象，不需要全局的对象来控制它的实例化
效果：客户不需要关心是否有其它实例存在，这是在它内部实现的
详细实例：http://www.cnblogs.com/xun126/archive/2011/03/09/1970807.html
适配器模式
需求问题：一个系统拥有正确的数据和行为，但是接口是错误的，实现不了全部的方法
意图：将一个无法控制的接口实现对象与一个自定的接口相匹配，从而在不影响该实现对象的接口的情况下，可以扩充方法（引用另一接口的实现中的方法）
效果：通过定义另外的接口并实现，并引用到现有的接口实现中，让其不受原有接口的限制，扩充方法，打破原有接口的局限性，适应新的类结构
实现：将现存的类包含在另外一个类中，包容类与需要的接口相匹配，并调用被包容类的方法
此外，也可以和其它的抽象类进行适配
桥接模式
需求问题：一个抽象类的派生类必须使用多种实现部分，但是又不能造成类爆炸等问题
意图：将一组实现部分从另一组使用它们的对象中分离出来
效果：实现部分与使用它的对象相分离，客户不需要了解实现问题
实现：为所有的实现部分定义一个接口，让抽象类的所有派生类使用这个接口
此外，注意过度的使用继承，容易造成类爆炸
观察者模式(报纸--订阅者)
需求问题：当某个事件发生时，你需要向一系列的对象发出通知，而这些对象是不断变化的
意图：在对象之间定义一种一对多的依赖关系，当一个对象的状态发生改变，所有依赖它的对象都将会的到通知并自动更新
详细实例：http://www.cnblogs.com/circleLee/archive/2011/07/21/2112912.html
装饰者模式
需求问题：附加功能时，可能出现在对象基础功能（创建）之前或之后
意图：为一个对象动态链接附加职责（动态的增加功能）
实现：创建一个抽象类来表示原始的类和要添加到这个类上的新功能。在装饰者类中，将对新功能的调用放到对象调用之前或之后
外观模式
需求问题：只需要使用一个复杂系统的子系统，或者需要一种特殊的方式与系统交互
意图：希望简化现有系统的使用方法
效果：该模式简化了对所需子系统的使用，但是，由于是子系统，所以系统的某些功能对客户不能开放
实现：定义一个或一组新的类来提供所需的接口；让新的类使用现有的系统
此外，外观模式也可以用来隐藏和包装原有的系统，方便跟踪和监视客户对原有系统的使用，以及改变我们原有的系统，实现和新系统的切换
小结
以上模式介绍的可能不是太多，最主要让大家理解。如果大家还是不太理解，下次我给大家找些例子看看，建议多找几本这样的书好好看看，最主要的是在以后项目中要多用，多
练，至少要多去接触，用的时间长了，你会理解更深，才叫真正的掌握，最好形成自己的一套开发风格。谢谢了！
