设计模式

对学到的设计模式做了简单的笔记

单例模式：

         饿汉式实现：

         饿汉式单例模式代码中，static变量会在类装载时初始化，此时也不会涉及多个线程对

         象访问该对象的问题。虚拟机保证只会装载一次该类，肯定不会发生并发访问的问题。

         因此，可以省略synchronized关键字。

         问题：如果只是加载本类，而不是调用getInstance（），甚至永远没有调用，则会造
         成资源浪费！

 

         懒汉式(单例对象延时加载）：

         要点：lazy load！  延时加载，懒加载！真正用的时候才加载！

         问题：资源利用率高了。但是，每次调用getInstance（）方法都要同步，并发效率低.      

         静态内部类实现方式（也是一种懒加载方式）

         要点：外部类没有static属性，则不会像饿汉式那样立即加载对象。

         只有真正调用getInstance（），才会加载静态内部类。加载类时是线程安全的。          

         instance是static final类型，保证了内存中只有这样一个实例存在，而且只能被赋                 值一次，从而保证了线程安全性兼备了并发高效调用和延迟加载的优势！

        

         枚举式(线程安全、调用效率高，不能延时加载，并且可以天然的防止反射和反序列化

         漏洞！)

 

         单例对象 占用资源少，不需要延时加载：   

         枚举式 好于饿汉式

         单例对象 占用资源大，需要延时加载：

         静态内部类式好于懒汉式

 

工厂模式：（面向对象设计的基本原则）：

         OCP（开闭原则）一个软件的实体应当对扩展开放，对修改关闭。

 

         DIP（依赖倒转原则，DependenceInversion Principle）：要针对接口编程，不要针 

         对实现编程。

         LoD（迪米特法则Law ofDemeter）：只与你直接的朋友通信，而避免和陌生人通信。

 

 

（创建型模式）

★原型模式：

         如果需要短时间创建大量对象，并且new的过程比较耗时。则可以考虑使用原型模式！

 

★单例模式：

         保证一个类只有一个实例，并且提供一个访问该实例的全局访问点。

 

工厂模式：

         ★简单工厂模式：用来生产同一等级结构中的任意产品。（对于增加新的产欧诺，需要    

         修改已有代码）

 

工厂方法模式：

         用来生产同一等级结构中的固定产品（支持增加任意产品）

 

抽象工厂模式：

         用来生产不同产品族的全部产品。（对于增加新的产品，无能为力；支持增加产 

         品族）

 

建造者模式：

         分离了对象子组件的单独构造（由Builder来负责）和装配（由Director负责）。从而 

         可以构造出复杂的对象。

 

 

（结构性模式：核心作用：是从程序的结构上实现松耦合，从而可以扩大整体的类结构，用来解

决更大的问题。）

 

代理模式：

         核心作用：通过代理，控制对对象的访问！  可以详细控制访问某个（某类）对象的方

         法，在调用这个方法前做前置处理，调用这个方法后做后置处理。（即：AOP的微观实

         现！）

 

动态代理：

         动态代理类的源码是在程序运行期间由JVM根据反射等机制动态的生成，所以不存在代理类的字节码文件。代理类和委托类的关系是在程序运行时确定。

 

静态代理

         由程序员创建或工具生成代理类的源码，再编译代理类。所谓静态也就是在程序运行前

         就已经存在代理类的字节码文件，代理类和委托类的关系在运行前就确定了。

 

桥接模式：

         桥接模式可以取代多层继承的方案。多层继承违背了单一职责原则，复用性较差，类

的个数也非常多。桥接模式可以极大的减少子类的个数，从而降低管理和维护的成本。

        

         桥接模式极大的提高了系统的可扩展性，在两个变化维度中任意扩展一个维度，都不需

         要修改原有的系统，符合开闭原则。

 

组合模式：

         使用组合模式的场景：把部分和整体的关系用树形结构来表示，从而使客户端可以使用

         统一的方式处理部分对象和整体对象。

        

         组合模式的核心：抽象构件（Component)角色：定义了叶子和容器构件的共同点

         叶子构件角色：无子节点

         容器（Composite）构件角色：有容器特征，可以包含子节点。

 

装饰模式：

         动态的为一个对象增加新的功能。

         装饰模式是一种用于代替继承的技术，无需通过继承增加子类就能扩展对象的新功能。

         使用对象的关联关系代替继承关系，更加灵活，同时避免类型体系的快速膨胀。

 

装饰模式和桥接模式的区别：

         两个模式都是为了解决过多子类对象问题。但他们的诱因不一样。桥接模式是对象自身   

         现有机制沿着多个维度变化，是既有部分不稳定。装饰模式是为了增加新的功能。

 

外观模式：

         迪米特法则（最少知识原则）：

         一个软件实体应当尽可能少的与其他实体发生互相作用。

         核心：为子系统提供统一的入口，封装子系统的复杂性，便于客户端调用。

 

享元模式：

         场景：内存属于稀缺资源，不要随便浪费。如果有很多个完全相同或相似的对象，我们可以通过享元模式，节省内存

         核心：享元模式以共享的方式高效地支持大量细粒度对象的重用。

                    享元模式能做到共享的关键是区分了内部状态和外部状态。

                          内部状态：可以共享，不会随环境变化而改变

                          外部状态：不可以共享，会随环境变化而改变

         优点：极大减少内存中对象的数量

                    相同或相似对象内存中只存一份，极大的节约资源，提高系统性能

                    外部状态相对独立，不影响内部状态

         缺点：模式较复杂，使程序逻辑复杂化

                    为了节省内存，共享了内部状态，分离出外部状态，而读取外部状态使运行时间               变长。用时间换取了空间。

 

行为模式：

责任链模式：将能够处理同一类请求的对象连成一条链，所提交的请求沿着链传递，链上的对象逐个判断是否有能力处理该请求，如果能则处理，如果不能则传递给链上的下一个对象。

场景：

打牌时，轮流出牌-----接力赛跑----大学中，奖学金审批------公司中，公文审批。

 

迭代器模式：提供一种可以遍历聚合对象的方式。又称为：游标cursor模式

                           聚合对象：存储数据

                           迭代器：遍历数据

 

中介者模式：解耦多个同事对象之间的交互关系。每个对象都持有中介者对象的引用，只跟中介者对象打交道。我们通过中介者对象统一管理这些交互关系。

 

命令模式：将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化；对请求排队或者请求日志，以及支持可撤销的操作。也称之为Action模式，事务transaction模式。

 

解释器模式：是一种不常用的设计模式，用于描述如何构成一个简单的语言解释器，主要用于使用面向对象语言开发的编译器和解释器设计。当我们需要开发一种新的语言时，可以考虑使用解释器模式。尽量不要使用解释器模式，后期维护会有很大麻烦。在项目中，可以使用Jurby、Groovy、java的js引擎来替代解释器的作用，弥补java语言的不足。

 

策略模式：策略模式对应于解决某个问题的一个算法族，允许用户从该算法族中任选一个算法解决某一问题，同时可以方便的更换算法或者增加新的算法。并且由客户端决定调用哪个算法。   本质：分离算法，选择实现。

 

模板方法模式：实现一个算法时，整体步骤很固定。但是，某些部分易变。易变部分可以抽象出来，供子类实现。

 

状态模式：用于解决系统中复杂对象的状态转换以及不同状态下行为的封装问题。

 

观察者模式：我们可以把多个订阅者、客户称之为观察者；需要同步给多个订阅者的数据封装到对象中，称之为目标。观察者模式主要用于： 1-N的通知。当一个对象（目标对象）的状态变化时，他需要及时告知一系列对象（观察者，Observer），令他们做出响应。每次都会把通知以广播方式发送给所有观察者，所有观察者只能被动接收。观察者只要知道有情况即可。至于什么时候获取内容，获取什么内容，都可以自主决定。

 

备忘录模式：就是保存某个对象内部状态的拷贝，这样以后就可以将该对象恢复到原先的状态。