个人所接触到的设计模式

本人学习的经验，有不妥之处请提出：

设计模式：
 一：简单工厂：减少对象之间的耦合，对象之间的调用隐藏起来了。如父类下面定义了多种子类，
        在工厂里面可以通过父类生成它的所有子类。
     简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。
     外界与具体类隔离开来，偶合性低。
     区分了各自的职责和权力，有利于整个软件体系结构的优化。
           
     项目中：service层调用dao层的实例，
     
 二：single单例模式：
         1.构造方法要用private修饰。
         2.方法要用同步(synchronized)
         3.方法与属性都要用静态(static)
         4.在方法里面对对象进行判断，如果不存在就创建一个，如果有了直接返回。

     项目中例用：连接Connection对象的时候，我们可以把它设为一个单例类，这样就会节省
        不必要的资源浪费了。
       
 三：stragegy策略模式：定义一系列的算法,把这些算法封装成单独的类, 并且使它们可相互替换。
    解决问题：某个具体的解决方法有很多种可选择的实现。
    例子：我们日常生活中常接触到的一个例子，如去超市购物，当我们买东西结账的时候我们
    可以支付现金，也可以选择用银行卡支付、也可以有其它的方法去支付。总之我们的钱减少了。
    这几种支付方式是可以自己选择的。
   
  策略模式(Strategy)的应用场景是:
    1. 多个类的分别只是在于行为不同
    2. 你需要对行为的算法做很多变动
    3. 客户不知道算法要使用的数据
 
 优点有：
    1.提供了管理相关的算法族的办法。可以把公共的代码移到父类里面，从而避免重复的代码。
    2.提供了可以替换继承关系的办法。继承可以处理多种算法或行为。使得动态改变算法或行为
    不可变。
    3. 使用策略模式可以避免使用多重条件转移语句。
  缺点有：
    1. 客户端必须知道所有的策略类，并自行决定使用哪一个策略类。只适用于客户端知道所有
    的算法或行为的情况。
    2. 策略模式造成很多的策略类。
 四：template模板模式：操作中算法的骨架，将一些步骤延迟到子类中去做。
    (也就是父类定义子类实现。)
     如我生成一个Person类，用abstract来修饰的，里面有一个抽象的方法。
     生成该类的一个子类，覆盖抽象方法，在该方法里面写一些业务逻辑。
     在调用的时候用父类声明，得到子类的对象，然后再调用父类里面的方法，它会自动得执行
     子类里面的方法。
   
     项目中的使用：父类定义一个排序的抽象方法，里面有一组数据。我们要对这组数据进行排序，
        调用这个方法就可以了。
    它下面有几个子类：A类，是用冒泡排序的。B类里面用的是插入排序。C类里面用的是希尔排序。
   我们要完成这组数据的排序，只要调用其中的一个就可以了，这样都可以达到我们想要的目的了。
   
  模板模式Template Method的应用场景是:
    1. 你想将相同的算法放在一个类中,将算法变化的部分放在子类中实现
    2. 子类公共的算法应该放在一个公共的类中,避免代码重复
 
     项目中：我们的项目中的SuperDao里面有增、删、查、改四个方法，其子类只要继承他，
     然后覆写里面的方法进行一些业务性的逻辑运算就可以了。

     五：observer观察者模式：对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,
     所有依赖于它的对象都得到通知并被自动更新。
     解决问题：解决多个对象间相互依赖关系的相互通知。
     常用地方：一些数据有多个视图的表示，譬如Java中自带的图形事件应用。
 
     举例：我家里有电话号码，而我和我哥要知道家里的电话号码以便于打电话回家，
        在这样的组合中，我家里的电话就是一个被观察者（Subject），我和我哥就是需要
        知道信息的观察者，当家里的电话号码发生改变时，我和我哥得到通知，
        并更新相应的电话记录。

     如火车站的时程表，如有时程表改变每个乘客都得要得到这个消息。
   
     项目：我以前写过的一个图书的管理系统，里面有很多的分类。例如：讲算机类、体育类、
        生活类等等。
    如果现再计算机类的书普通客户是打9折的，而会员则打7析。但是老板发现生意不太好，
        于是就进行了调整将原来的9折改为7折，会员价改为6折。这时我们不需要对其源代码
        进行改变，只要将在调用的时候在加另一个对象就可以了，如果以后要改回来的时候，
        也只要把现再的给注释掉，然后换成以前的就可以了。
   
   
 六：component组合模式：将对象以树形结构组织起来,以达成“部分－整体”的层次结构，
    使得客户端对单个对象和组合对象的使用具有一致性.

    解决问题:树形数据结构的方案

    适用性:
        你想表示对象的部分-整体层次结构。
        你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。

    例：我们公司有不同的部门，而我们开发的有几个团队。如在一次做项目的时候我们这个团队提前完成了
    任务，这个月我们团队可以加工资了，也就说我们团队的每个人都要加工资。这时账务科的只要把我们这个
    团队记上加工资就可以了，不需要一个一个的去加了。
   
 七：command命令模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化
 
    解决问题:只关心行为,不关心具体执行类或者实现.
    什么情况下用：多级undo操作、原子事务行为、导航
   
    项目中的使用：例如我以前做过的ATM自动取款机的项目，我们的一系列操作都是一条命令去控制的，
     在取款的过程中我们并不需要它是怎么实现的，如那钱是怎么出来的，你不需要关心，你要关心的是你
     点击了取款，你要取多少它就会给你多少。
     
   八：facade外观模式、门面模式：为子系统中的一组接口提供一个一致的interface接口界面。
   解决问题：子接口繁多，调用复杂，内部交互地方比较多
   例如：在一个泡茶的过程中，需要作如下的工作：烧开水，准备茶叶，把茶叶放在杯子里，把烧开的水放到
        茶杯中，只有经过这些过程之后才能泡出好的茶叶来。可以把这些动作串联起来，形成一个整体的步骤，
        就是MakeACuppa()，这样在调用步方法时也比较方便。把里面的细节被屏蔽掉了。
       
        比如，现在有一辆汽车，我们（客户程序）要启动它，那我们就要发动引擎（子系统1），使四个车轮
        （子系统2）转动。但是实际中我们并不需要用手推动车轮使其转动，我们踩下油门，此时汽车再根据
        一些其他的操作使车轮转动。油门就好比系统给我们留下的接口，不论汽车是以何种方式转动车轮，
        车轮变化成什么牌子的，我们要开走汽车所要做的还是踩下油门。
   
    九：decorator装饰器模式定义：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。
        解决问题：一个对象需要经常动态增加属性或职责
例子：我以前写过的一个网上购物系统，如果现再有一款新的产品进来了，我只需要动态的把它加到
产品当中去就可以了，而不是把里面的代码再重新改一遍，当某类产品不想再出售的时候我们只
             需要在调用的那里把这类产品删除掉就可以了。
              
    十：state状态模式：当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。
      觖决问题：适合"状态的切换".因为我们经常会使用If elseif else 进行状态切换,
      如果针对状态的这样判断切换反复出现,我们就要联想到是否可以采取State模式了.
     项目：我以前做过的一人业务发放系统，在这里面我们就用到了状态模式，在卖给客户的时候
     有一定的时间的。并不是永久性的，他在到期的前几天你使用的时候会发出一个警报，只是轻微的告警而
     已，告诉你这个快要过期了，可能有部分的功能不能用了，当到期后你再使用，他会给出很严重的告警，
     这时你已经不能使用了。这里该系统的这些状态就是通过状态模式来完成的。
    十一：chain职责链模式：使为了避免请求的发送者和接收者之间的耦合关系，使多个接受对象都有机会
    处理请求
    解决问题
    1 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
    2 你想在不明确指定接受者的情况下，向多个对象中的一个提交一个请求。
    3 可处理一个请求的对象集合应该被动态指定。
    例子：比如工厂里面的生产流水线，每条流水线上面都有一些工作人员，这些工作人员就好比一个对象。
         如果这其中的一个工作人员走了，也不影响这条流水线的工作，如果这条流水线又来的一个员工，
     也不影响这条流水线的工作。

     十二：Abstract Factory，抽象工厂：提供一个创建一系列相关或相互依赖对象的接口，
        而无须指定它们的具体类。
        解决：一个系统要独立于它的产品的创建、组合和表示时。
              一个系统要由多个产品系列中的一个来配置时。
     例子：例如诺基亚手机生产商，他肯定不只是造那一款手机吧，例如：5800、E71、N97等。
         他肯定不是一个人把整部手机都完成的，每个人只负责其中的一块。
         如一部分是造按键的、一部分是造屏幕的、一部分是造外壳的。
         
     十三：Adapter适配器模式，将一个类装换成客户期望的另外一个接口。Adapter模式使的
        原本由于接口不兼容而不能工作的那些类可以一起工作。
     解决了：组件的接口与目前系统接口不兼容，可以使用适配器模式解决接口不兼容问题。   
     分为类适配器与对象适配器：    
     1.类适配器模式需要创建自身来创建一个Adaptee,
        对象适配器模式可以直接使用一个已有的Adaptee的实例来转换接口。
     2. 类适配器继承了Adaptee,所以可以通过覆写来扩展SpecificRequest()
        对象适配器和Adaptee是包含关系不能扩展;(其实也可以扩展的见下面)
     3.类适配器模式因为是继承所以相对静态，而对象适配器模式是包含是组合相对灵活
     (可以通过写adaptee子类扩展功能)
     组合优于继承
     例子：手机充电器
     
     十四：Builder，建造模式：将一个复杂对象的构建与他的表示相分离，使得同样的构建
        过程可以创建不同的表示。
     适用：当构造过程必须允许被构造的对象有不同的表示时。
     解决：将构建复杂对象的过程和它的部件解耦。
     例子：如造手机
     
     十五：代理模式：为其他对象提供一种代理以控制对这个对象的访问。
     特征是代理类与委托类有同样的接口，代理类主要负责为委托类预处理消息、过滤消息、把消息
        转发给委托类，以及事后处理消息等。
     静态代理类：由程序员创建或由特定工具自动生成源代码，再对其编译。在程序运行前，
        代理类的.class文件就已经存在了。
　　 动态代理类：在程序运行时，运用反射机制动态创建而成。
     例子：如一个网上购物系统，你如果在这里买了东西付了钱，他就会给你东西。会是老板自己
     来送给你吗，不是，他会通过一个代理然后再把东西交到你的手上。
     
     十六：中介模式：用一个中介对象来封装一系列的对象交互。
     MVC中的控制层就好比一个中介的作用。
好处：使用中介者模式最大的好处就是将同事角色解耦。这带来了一系列的系统结构改善：提高了原有系统的可读性、简化原有系统的通信协议——将原有的多对多变为一对多、提高了代码的可复用性