软件系统设计-9-外观模式、享元模式和代理模式

1. 外观模式

1.1. 模式动机

1.4. 模式分析

1. 根据“单一职责原则”，在软件中将一个系统划分为若干个子系统有利于降低整个系统的复杂性，一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小，而达到该目标的途径之一就是引入一个外观对象，它为子系统的访问提供了一个简单而单一的入口。
2. 外观模式也是“迪米特法则”的体现，通过引入一个新的外观类可以降低原有系统的复杂度，同时降低客户类与子系统类的耦合度。
3. 外观模式要求一个子系统的外部与其内部的通信通过一个统一的外观对象进行，外观类将客户端与子系统的内部复杂性分隔开，使得客户端只需要与外观对象打交道，而不需要与子系统内部的很多对象打交道。
4. 外观模式的目的在于降低系统的复杂程度。
5. 外观模式从很大程度上提高了客户端使用的便捷性，使得客户端无须关心子系统的工作细节，通过外观角色即可调用相关功能。
6. 典型的外观角色代码：

1.5. 外观模式实例与解析

1.5.1. 实例一：电源总开关

1. 现在考察一个电源总开关的例子，以便进一步说明外观模式。为了使用方便，一个电源总开关可以控制四盏灯、一个风扇、一台空调和一台电视机的启动和关闭。通过该电源总开关可以同时控制上述所有电器设备，使用外观模式设计该系统。

2. 可以使用模板方法模式实现嘛类提供不同的实现，复用父类方法的步骤
3. 什么时候外观果每一个部分都不变，只是提供接口

1.6. 模式优缺点

1.6.1. 外观模式的优点

1. 对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式，客户代码将变得很简单，与之关联的对象也很少。
2. 实现了子系统与客户之间的松耦合关系，这使得子系统的组件变化不会影响到调用它的客户类，只需要调整外观类即可。
3. 降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。
4. 只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类。

1.6.2. 外观模式的缺点

1. 不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
2. 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

1.6.3. 外观模式

1. 模式适用环境
   1. 在以下情况下可以使用外观模式：
   2. 当要为一个复杂子系统提供一个简单接口时可以使用外观模式。该接口可以满足大多数用户的需求，而且用户也可以越过外观类直接访问子系统。
   3. 客户程序与多个子系统之间存在很大的依赖性。引入外观类将子系统与客户以及其他子系统解耦，可以提高子系统的独立性和可移植性。
   4. 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。

1.7. 模式应用

1. 外观模式应用于JDBC数据库操作

2. Session外观模式是外观模式在Java EE框架中的应用。

1.9. 小结

1. 在外观模式中，外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。外观模式又称为门面模式，它是一种对象结构型模式。
2. 外观模式包含两个角色
   1. 外观角色是在客户端直接调用的角色，在外观角色中可以知道相关的(一个或者多个)子系统的功能和责任，它将所有从客户端发来的请求委派到相应的子系统去，传递给相应的子系统对象处理
   2. 在软件系统中可以同时有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能。
3. 外观模式要求一个子系统的外部与其内部的通信通过一个统一的外观对象进行，外观类将客户端与子系统的内部复杂性分隔开，使得客户端只需要与外观对象打交道，而不需要与子系统内部的很多对象打交道。
4. 外观模式
   1. 主要优点在于对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易，它实现了子系统与客户之间的松耦合关系，并降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程
   2. 其缺点在于不能很好地限制客户使用子系统类，而且在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。
5. 外观模式适用情况包括
   1. 要为一个复杂子系统提供一个简单接口
   2. 客户程序与多个子系统之间存在很大的依赖性
   3. 在层次化结构中，需要定义系统中每一层的入口，使得层与层之间不直接产生联系。

2. 享元模式

2.1. 模式动机

1. 面向对象技术可以很好地解决一些灵活性或可扩展性问题，但在很多情况下需要在系统中增加类和对象的个数。当对象数量太多时，将导致运行代价过高，带来性能下降等问题。
2. 享元模式正是为解决这一类问题而诞生的。享元模式通过共享技术实现相同或相似对象的重用。

1. 享元工厂和原型管理器非常相似
2. 享元模式包含如下角色：
   1. Flyweight: 抽象享元类
   2. ConcreteFlyweight: 具体享元类
   3. UnsharedConcreteFlyweight: 非共享具体享元类
   4. FlyweightFactory: 享元工厂类
3. 享元模式是一个考虑系统性能的设计模式，通过使用享元模式可以节约内存空间，提高系统的性能。

2.6. 模式优缺点

2.6.1. 享元模式的优点

1. 享元模式的优点在于它可以极大减少内存中对象的数量，使得相同对象或相似对象在内存中只保存一份。
2. 享元模式的外部状态相对独立，而且不会影响其内部状态，从而使得享元对象可以在不同的环境中被共享。

2.6.2. 享元模式的缺点

1. 享元模式使得系统更加复杂，需要分离出内部状态和外部状态，这使得程序的逻辑复杂化。
2. 为了使对象可以共享，享元模式需要将享元对象的状态外部化，而读取外部状态使得运行时间变长。

2.7. 模式适用环境

1. 在以下情况下可以使用享元模式：
   1. 一个系统有大量相同或者相似的对象，由于这类对象的大量使用，造成内存的大量耗费。
   2. 对象的大部分状态都可以外部化，可以将这些外部状态传入对象中。
   3. 使用享元模式需要维护一个存储享元对象的享元池，而这需要耗费资源，因此，应当在多次重复使用享元对象时才值得使用享元模式。

2.8. 模式应用

1. 在JDK类库中定义的String类使用了享元模式。

2.9. 模式扩展

2.9.1. 单纯享元模式和复合享元模式

1. 单纯享元模式：在单纯享元模式中，所有的享元对象都是可以共享的，即所有抽象享元类的子类都可共享，不存在非共享具体享元类。

2.9.2. 享元模式与其他模式的联用

1. 在享元模式的享元工厂类中通常提供一个静态的工厂方法用于返回享元对象，使用简单工厂模式来生成享元对象。
2. 在一个系统中，通常只有唯一一个享元工厂，因此享元工厂类可以使用单例模式进行设计。
3. 享元模式可以结合组合模式形成复合享元模式，统一对享元对象设置外部状态。

2.10. 小结

1. 享元模式运用共享技术有效地支持大量细粒度对象的复用。系统只使用少量的对象，而这些对象都很相似，状态变化很小，可以实现对象的多次复用，它是一种对象结构型模式。
2. 享元模式包含四个角色
   1. 抽象享元类声明一个接口，通过它可以接受并作用于外部状态
   2. 具体享元类实现了抽象享元接口，其实例称为享元对象；非共享具体享元是不能被共享的抽象享元类的子类
   3. 享元工厂类用于创建并管理享元对象，它针对抽象享元类编程，将各种类型的具体享元对象存储在一个享元池中。
3. 享元模式以共享的方式高效地支持大量的细粒度对象，享元对象能做到共享的关键是区分内部状态和外部状态。其中内部状态是存储在享元对象内部并且不会随环境改变而改变的状态，因此内部状态可以共享；外部状态是随环境改变而改变的、不可以共享的状态。
4. 享元模式
   1. 主要优点在于它可以极大减少内存中对象的数量，使得相同对象或相似对象在内存中只保存一份
   2. 其缺点是使得系统更加复杂，并且需要将享元对象的状态外部化，而读取外部状态使得运行时间变长。
5. 享元模式适用情况包括
   1. 一个系统有大量相同或者相似的对象，由于这类对象的大量使用，造成内存的大量耗费
   2. 对象的大部分状态都可以外部化，可以将这些外部状态传入对象中；多次重复使用享元对象。

3. 代理模式

3.1. 模式动机

1. 在某些情况下，一个客户不想或者不能直接引用一个对象，此时可以通过一个称之为“代理”的第三者来实现间接引用。代理对象可以在客户端和目标对象之间起到中介的作用，并且可以通过代理对象去掉客户不能看到的内容和服务或者添加客户需要的额外服务。

1. 通过引入一个新的对象（如小图片和远程代理对象）来实现对真实对象的操作或者将新的对象作为真实对象的一个替身，这种实现机制即为代理模式，通过引入代理对象来间接访问一个对象，这就是代理模式的模式动机。

3.2. 模式定义

1. 代理模式(Proxy Pattern) ：给某一个对象提供一个代理，并由代理对象控制对原对象的引用。代理模式的英文叫做Proxy或Surrogate，它是一种对象结构型模式。
2. Proxy Pattern: Provide a surrogate or placeholder for another object to control access to it.
3. 思想简单，但是变体很多

3.3. 模式结构

1. 代理模式包含如下角色：
   1. Subject: 抽象主题角色
   2. Proxy: 代理主题角色
   3. RealSubject: 真实主题角色
2. Proxy是符合迪米特法则的。

3.4. 模式分析

1. 代理模式示意结构图比较简单，一般可以简化为如下图所示，但是在现实中要复杂很多。
2. 典型的代理类实现代码：

public class Proxy implements Subject{  private RealSubject realSubject = new RealSubject();  public void preRequest()

                                                        
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！