Structural model describes how to press a certain layout of the class or object into larger structures. It is divided into objects and class structural model structural model, the former using the inheritance mechanism to organize classes and interfaces, which preclude the use of polymeric compositions or combined objects.
Due to the combination or aggregate relationship inheritance relationship lower than the coupling relations to meet the "synthetic multiplexing principle", the structural model objects having greater flexibility than the class structure schema.
Structural model is divided into seven types:
- Proxy (Proxy) mode: an object to provide an agent for controlling access to the object. I.e., indirectly via a proxy client to access the object, thereby limiting, enhance or modify some features of the object.
- Adapter (Adapter) mode: converting a class interface clients expect another interface, such as those due to incompatible interfaces based otherwise not able to work together with the work.
- Bridge (Bridge) mode: an abstraction and separation, so that they may be varied independently. It is achieved by a combination relationship instead of inheritance, and abstraction implemented to reduce the dimensions of the two variable degree of coupling.
- Decoration (Decorator) mode: dynamically add some responsibilities to an object, that is, to increase its extra features.
- Appearance (the Facade) mode: providing a consistent interface to multiple complex subsystems, these subsystems are more easily accessible.
- Flyweight (Flyweight) mode: Use sharing to support effective reuse a lot of fine-grained objects.
- A combination of (Composite) mode: the objects into the hierarchy tree, so that the user has access to the same combination of the object and the individual objects.
7 more structural model, in addition to the adapter mode into two categories structural model and two modes of structural objects, objects belonging to all the other structural model, the following we will respectively introduce their characteristics, structure and application in more detail.
1, proxy mode
1) For some reason need to give an object to provide a control access to the object proxy. In this case, the object does not fit or can not access a direct reference to the target object, a proxy object as an intermediary between the access and target objects.
The main advantage of proxy mode are:
- Proxy mode to play a mediating role and protect the role of the target object between the client and the target object;
- Proxy object can extend the function of the target object;
- Client proxy mode capable of separating the target object, the coupling degree is reduced to some extent;
The main disadvantages are:
- Between the client and the target object is a proxy object to increase, will cause the slow request processing;
- It increases the complexity of the system;
2) Architecture and Implementation
The main role of the agency model as follows.
- Abstract topics (Subject) categories: real business methods and themes proxy object achieved by the interface or abstract class declaration.
- Real theme (Real Subject) category: abstract achieve specific business topics, real object is represented by a proxy object, the object is to be the ultimate reference.
- Proxy (Proxy) class: provides the same interface with the real theme, the interior contains a reference to the real subject, it can access, control, or extend the functionality of the real theme.
// abstract theme interface Subject { void Request (); } // real theme class RealSubject the implements Subject { public void Request () { System.out.println ( "access real thematic approach ..." ); } } // proxy class the Proxy the implements the Subject { Private RealSubject RealSubject; public void the Request () { IF (RealSubject == null ) { RealSubject = new new RealSubject (); } preRequest (); realSubject.Request (); postRequest (); } public void preRequest () { System.out.println ( "pretreatment prior to access real theme." ); } public void postRequest () { System.out.println ( "the subsequent process after accessing the real theme." ); } }
public class ProxyTest { public static void main(String[] args) { Proxy proxy=new Proxy(); proxy.Request(); } }
result:
Pretreatment prior to access real theme.
Access method ... real theme
subsequent processing after the real theme of the visit.
3) application scenarios
- Remote Agent, this approach is usually to hide the fact that the target object exists in different address spaces, to facilitate client access. For example, when users apply some network disk space, creates a virtual hard disk in the user's file system, users access the virtual hard disk is actually access the network disk space.
- Alerts, this approach is typically used when you want to create audience much overhead. For example, downloading a large image takes a long time for some short period of time to calculate more complex and can not be completed, then you can start with a virtual agent to replace real objects small proportion, eliminate the user the feeling of a slow server.
- Security agent, this approach typically used to control different types of customers access to the real object.
- Intelligent guidance is mainly used when calling the target object, a proxy attach some additional processing functions. Calculating a real object, for example increased, the number of reference function, so that when the object is not referenced, it can be automatically released.
- Lazy loading, refer to in order to improve system performance, delayed loading of the target. For example, the Hibernate on the existence and properties associated delay loading delay loading table.
4) Extended
In proxy mode described earlier, the proxy class contains a reference to the real topic, there are two drawbacks to this approach.
- The real subject of correspondence with the agent theme, the theme should be increased to increase the real agent.
- Design agency before the real theme must already exist, less flexible. Dynamic proxy mode can solve the above problem, such as the Spring the AOP, the structure shown in Figure 4
2, the adapter mode (Adapter)
1) converting a class interface clients expect another interface, such as those due to incompatible interfaces based otherwise not able to work together with the work. Adapter mode is divided into mode-based structural and structural objects two modes, coupling between the former than the latter category, a programmer is required and the internal structure of the conventional component library related components, it is relatively seldom used some.
The main advantage of this mode is as follows.
- The client can transparently invoke the target through the interface adapter.
- Multiplexed with the existing class, the programmer need not modify the original code reuse existing classes fitter.
- The target class and the class of decoupled fitter solve the problem of the target class and the class interface adapter are inconsistent.
Its disadvantages are: the class adapter, the adapter replace the realization of a more complex process.
2) Architecture and Implementation
Adapter mode (Adapter) contains the following major role.
- Target (Target) Interface: the current system of business expected interface, which can be abstract classes or interfaces.
- Fitter (the Adaptee) Class: it is being accessed and an interface component adapted existing component library.
- Adapter (Adapter) class: it is a converter, by inheritance or referenced objects fitter and fitter conversion interface into the target interface, according to the destination interface to allow customers to access the adapter's format.
Class adapter modes:
package adapter; //目标接口 interface Target { public void request(); } //适配者接口 class Adaptee { public void specificRequest() { System.out.println("适配者中的业务代码被调用！"); } } //类适配器类 class ClassAdapter extends Adaptee implements Target { public void request() { specificRequest(); } } //客户端代码 public class ClassAdapterTest { public static void main(String[] args) { System.out.println("类适配器模式测试："); Target target = new ClassAdapter(); target.request(); } }
运行结果：
类适配器模式测试：
适配者中的业务代码被调用！
对象适配器模式：
package adapter; //对象适配器类 class ObjectAdapter implements Target { private Adaptee adaptee; public ObjectAdapter(Adaptee adaptee) { this.adaptee=adaptee; } public void request() { adaptee.specificRequest(); } } //客户端代码 public class ObjectAdapterTest { public static void main(String[] args) { System.out.println("对象适配器模式测试："); Adaptee adaptee = new Adaptee(); Target target = new ObjectAdapter(adaptee); target.request(); } }
运行结果：
对象适配器模式测试：
适配者中的业务代码被调用！
说明：对象适配器模式中的“目标接口”和“适配者类”的代码同类适配器模式一样，只要修改适配器类和客户端的代码即可。
3）应用场景
适配器模式（Adapter）通常适用于以下场景。
- 以前开发的系统存在满足新系统功能需求的类，但其接口同新系统的接口不一致。
- 使用第三方提供的组件，但组件接口定义和自己要求的接口定义不同。
4）扩展
适配器模式（Adapter）可扩展为双向适配器模式，双向适配器类既可以把适配者接口转换成目标接口，也可以把目标接口转换成适配者接口
3、桥接（Bridge）模式
1）将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
桥接（Bridge）模式的优点是：
- 由于抽象与实现分离，所以扩展能力强；
- 其实现细节对客户透明。
缺点是：由于聚合关系建立在抽象层，要求开发者针对抽象化进行设计与编程，这增加了系统的理解与设计难度。
2）结构与实现
桥接（Bridge）模式包含以下主要角色。
- 抽象化（Abstraction）角色：定义抽象类，并包含一个对实现化对象的引用。
- 扩展抽象化（Refined Abstraction）角色：是抽象化角色的子类，实现父类中的业务方法，并通过组合关系调用实现化角色中的业务方法。
- 实现化（Implementor）角色：定义实现化角色的接口，供扩展抽象化角色调用。
- 具体实现化（Concrete Implementor）角色：给出实现化角色接口的具体实现。
public class BridgeTest { public static void main(String[] args) { Implementor imple=new ConcreteImplementorA(); Abstraction abs=new RefinedAbstraction(imple); abs.Operation(); } } //实现化角色 interface Implementor { public void OperationImpl(); } //具体实现化角色 class ConcreteImplementorA implements Implementor { public void OperationImpl() { System.out.println("具体实现化(Concrete Implementor)角色被访问" ); } } //抽象化角色 abstract class Abstraction { protected Implementor imple; protected Abstraction(Implementor imple) { this.imple=imple; } public abstract void Operation(); } //扩展抽象化角色 class RefinedAbstraction extends Abstraction { protected RefinedAbstraction(Implementor imple) { super(imple); } public void Operation() { System.out.println("扩展抽象化(Refined Abstraction)角色被访问" ); imple.OperationImpl(); } }
运行结果
扩展抽象化(Refined Abstraction)角色被访问
具体实现化(Concrete Implementor)角色被访问
3）应用场景
桥接模式通常适用于以下场景。
- 当一个类存在两个独立变化的维度，且这两个维度都需要进行扩展时。
- 当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时。
- 当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时。
4）扩展
在软件开发中，有时桥接（Bridge）模式可与适配器模式联合使用。当桥接（Bridge）模式的实现化角色的接口与现有类的接口不一致时，可以在二者中间定义一个适配器将二者连接起来
4、装饰（Decorator）模式
1）指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式，它属于对象结构型模式。
装饰（Decorator）模式的主要优点有：
- 采用装饰模式扩展对象的功能比采用继承方式更加灵活。
- 可以设计出多个不同的具体装饰类，创造出多个不同行为的组合。
其主要缺点是：装饰模式增加了许多子类，如果过度使用会使程序变得很复杂。
2）结构与实现
通常情况下，扩展一个类的功能会使用继承方式来实现。但继承具有静态特征，耦合度高，并且随着扩展功能的增多，子类会很膨胀。如果使用组合关系来创建一个包装对象（即装饰对象）来包裹真实对象，并在保持真实对象的类结构不变的前提下，为其提供额外的功能，这就是装饰模式的目标。
装饰模式主要包含以下角色。
- 抽象构件（Component）角色：定义一个抽象接口以规范准备接收附加责任的对象。
- 具体构件（Concrete Component）角色：实现抽象构件，通过装饰角色为其添加一些职责。
- 抽象装饰（Decorator）角色：继承抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能。
- 具体装饰（ConcreteDecorator）角色：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任。
public class DecoratorPattern { public static void main(String[] args) { Component p=new ConcreteComponent(); p.operation(); System.out.println("---------------------------------"); Component d=new ConcreteDecorator(p); d.operation(); } } //抽象构件角色 interface Component { public void operation(); } //具体构件角色 class ConcreteComponent implements Component { public ConcreteComponent() { System.out.println("创建具体构件角色"); } public void operation() { System.out.println("调用具体构件角色的方法operation()"); } } //抽象装饰角色 class Decorator implements Component { private Component component; public Decorator(Component component) { this.component=component; } public void operation() { component.operation(); } } //具体装饰角色 class ConcreteDecorator extends Decorator { public ConcreteDecorator(Component component) { super(component); } public void operation() { super.operation(); addedFunction(); } public void addedFunction() { System.out.println("为具体构件角色增加额外的功能addedFunction()"); } }
运行结果
创建具体构件角色 调用具体构件角色的方法operation() --------------------------------- 调用具体构件角色的方法operation() 为具体构件角色增加额外的功能addedFunction()
3）应用场景
前面讲解了关于装饰模式的结构与特点，下面介绍其适用的应用场景，装饰模式通常在以下几种情况使用。
- 当需要给一个现有类添加附加职责，而又不能采用生成子类的方法进行扩充时。例如，该类被隐藏或者该类是终极类或者采用继承方式会产生大量的子类。
- 当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时，采用继承关系很难实现，而采用装饰模式却很好实现。
- 当对象的功能要求可以动态地添加，也可以再动态地撤销时。
装饰模式在 Java 语言中的最著名的应用莫过于 Java I/O 标准库的设计了。例如，InputStream 的子类 FilterInputStream，OutputStream 的子类 FilterOutputStream，Reader 的子类 BufferedReader 以及 FilterReader，还有 Writer 的子类 BufferedWriter、FilterWriter 以及 PrintWriter 等，它们都是抽象装饰类。
下面代码是为 FileReader 增加缓冲区而采用的装饰类 BufferedReader 的例子：
BufferedReader in=new BufferedReader(new FileReader("filename.txtn)); String s=in.readLine();
4）扩展
装饰模式所包含的 4 个角色不是任何时候都要存在的，在有些应用环境下模式是可以简化的，如以下两种情况。
(1) 如果只有一个具体构件而没有抽象构件时，可以让抽象装饰继承具体构件
(2) 如果只有一个具体装饰时，可以将抽象装饰和具体装饰合并
5、外观（Facade）模式
1）是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。
外观（Facade）模式是“迪米特法则”的典型应用，它有以下主要优点。
- 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
- 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
- 降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。
外观（Facade）模式的主要缺点如下。
- 不能很好地限制客户使用子系统类。
- 增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。
2）结构与实现
外观（Facade）模式的结构比较简单，主要是定义了一个高层接口。它包含了对各个子系统的引用，客户端可以通过它访问各个子系统的功能。现在来分析其基本结构和实现方法。
外观（Facade）模式包含以下主要角色。
- 外观（Facade）角色：为多个子系统对外提供一个共同的接口。
- 子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。
- 客户（Client）角色：通过一个外观角色访问各个子系统的功能。
public class FacadePattern { public static void main(String[] args) { Facade f=new Facade(); f.method(); } } //外观角色 class Facade { private SubSystem01 obj1=new SubSystem01(); private SubSystem02 obj2=new SubSystem02(); private SubSystem03 obj3=new SubSystem03(); public void method() { obj1.method1(); obj2.method2(); obj3.method3(); } } //子系统角色 class SubSystem01 { public void method1() { System.out.println("子系统01的method1()被调用！"); } } //子系统角色 class SubSystem02 { public void method2() { System.out.println("子系统02的method2()被调用！"); } } //子系统角色 class SubSystem03 { public void method3() { System.out.println("子系统03的method3()被调用！"); } }
运行结果
子系统01的method1()被调用！
子系统02的method2()被调用！
子系统03的method3()被调用！
3）应用场景
通常在以下情况下可以考虑使用外观模式。
- 对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
- 当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问。
- 当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。
4）扩展
在外观模式中，当增加或移除子系统时需要修改外观类，这违背了“开闭原则”。如果引入抽象外观类，则在一定程度上解决了该问题
6、享元（Flyweight）模式
1）运用共享技术来有効地支持大量细粒度对象的复用。它通过共享已经存在的又橡来大幅度减少需要创建的对象数量、避免大量相似类的开销，从而提高系统资源的利用率。
享元模式的主要优点是：相同对象只要保存一份，这降低了系统中对象的数量，从而降低了系统中细粒度对象给内存带来的压力。
其主要缺点是：
- 为了使对象可以共享，需要将一些不能共享的状态外部化，这将增加程序的复杂性。
- 读取享元模式的外部状态会使得运行时间稍微变长。
2）结构与实现
享元模式中存在以下两种状态：
- 内部状态，即不会随着环境的改变而改变的可共享部分；
- 外部状态，指随环境改变而改变的不可以共享的部分。享元模式的实现要领就是区分应用中的这两种状态，并将外部状态外部化。下面来分析其基本结构和实现方法。
享元模式的主要角色有如下。
- 抽象享元角色（Flyweight）:是所有的具体享元类的基类，为具体享元规范需要实现的公共接口，非享元的外部状态以参数的形式通过方法传入。
- 具体享元（Concrete Flyweight）角色：实现抽象享元角色中所规定的接口。
- 非享元（Unsharable Flyweight)角色：是不可以共享的外部状态，它以参数的形式注入具体享元的相关方法中。
- 享元工厂（Flyweight Factory）角色：负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检査系统中是否存在符合要求的享元对象，如果存在则提供给客户；如果不存在的话，则创建一个新的享元对象。
图中的 UnsharedConcreteFlyweight 是与享元角色，里面包含了非共享的外部状态信息 info；而 Flyweight 是抽象享元角色，里面包含了享元方法 operation(UnsharedConcreteFlyweight state)，非享元的外部状态以参数的形式通过该方法传入；ConcreteFlyweight 是具体享元角色，包含了关键字 key，它实现了抽象享元接口；FlyweightFactory 是享元工厂角色，它逝关键字 key 来管理具体享元；客户角色通过享元工厂获取具体享元，并访问具体享元的相关方法。
import java.util.HashMap; public class FlyweightPattern { public static void main(String[] args) { FlyweightFactory factory=new FlyweightFactory(); Flyweight f01=factory.getFlyweight("a"); Flyweight f02=factory.getFlyweight("a"); Flyweight f03=factory.getFlyweight("a"); Flyweight f11=factory.getFlyweight("b"); Flyweight f12=factory.getFlyweight("b"); f01.operation(new UnsharedConcreteFlyweight("第1次调用a。")); f02.operation(new UnsharedConcreteFlyweight("第2次调用a。")); f03.operation(new UnsharedConcreteFlyweight("第3次调用a。")); f11.operation(new UnsharedConcreteFlyweight("第1次调用b。")); f12.operation(new UnsharedConcreteFlyweight("第2次调用b。")); } } //非享元角色 class UnsharedConcreteFlyweight { private String info; UnsharedConcreteFlyweight(String info) { this.info=info; } public String getInfo() { return info; } public void setInfo(String info) { this.info=info; } } //抽象享元角色 interface Flyweight { public void operation(UnsharedConcreteFlyweight state); } //具体享元角色 class ConcreteFlyweight implements Flyweight { private String key; ConcreteFlyweight(String key) { this.key=key; System.out.println("具体享元"+key+"被创建！"); } public void operation(UnsharedConcreteFlyweight outState) { System.out.print("具体享元"+key+"被调用，"); System.out.println("非享元信息是:"+outState.getInfo()); } } //享元工厂角色 class FlyweightFactory { private HashMap<String, Flyweight> flyweights=new HashMap<String, Flyweight>(); public Flyweight getFlyweight(String key) { Flyweight flyweight=(Flyweight)flyweights.get(key); if(flyweight!=null) { System.out.println("具体享元"+key+"已经存在，被成功获取！"); } else { flyweight=new ConcreteFlyweight(key); flyweights.put(key, flyweight); } return flyweight; } }
运行结果
具体享元a被创建！
具体享元a已经存在，被成功获取！
具体享元a已经存在，被成功获取！
具体享元b被创建！
具体享元b已经存在，被成功获取！
具体享元a被调用，非享元信息是:第1次调用a。
具体享元a被调用，非享元信息是:第2次调用a。
具体享元a被调用，非享元信息是:第3次调用a。
具体享元b被调用，非享元信息是:第1次调用b。
具体享元b被调用，非享元信息是:第2次调用b。
3）应用场景
享元模式是通过减少内存中对象的数量来节省内存空间的，所以以下几种情形适合采用享元模式。
- 系统中存在大量相同或相似的对象，这些对象耗费大量的内存资源。
- 大部分的对象可以按照内部状态进行分组，且可将不同部分外部化，这样每一个组只需保存一个内部状态。
- 由于享元模式需要额外维护一个保存享元的数据结构，所以应当在有足够多的享元实例时才值得使用享元模式。
4）扩展
在前面介绍的享元模式中，其结构图通常包含可以共享的部分和不可以共享的部分。在实际使用过程中，有时候会稍加改变，即存在两种特殊的享元模式：单纯享元模式和复合享元模式，
(1) 单纯享元模式，这种享元模式中的所有的具体享元类都是可以共享的，不存在非共享的具体享元类
(2) 复合享元模式，这种享元模式中的有些享元对象是由一些单纯享元对象组合而成的，它们就是复合享元对象。虽然复合享元对象本身不能共享，但它们可以分解成单纯享元对象再被共享
原文链接：http://c.biancheng.net/design_pattern/