结构型设计模式

结构型设计模式概述 

结构型设计模式用于处理类或对象之间的组合，即描述类和对象之间怎样组织起来形成大的结构，从而实现新的功能。

实现的机制：

结构型对象模式采用组合/聚合机制来组合类，包括桥梁模式（Bridge）、组合模式（Composite）、装饰器模式（Decorator）、外观模式（Facade）、享元模式（FlyWeight）、代理模式（Proxy）。

结构型类模型采用继承机制来组合类，包括适配器模式（Adapter）。

（一）外观(Facade)模式（门面模式） 

问题提出：

在软件系统中，客户程序经常会与复杂系统的内部子系统之间产生耦合，而导致客户程序随着子系统的变化而变化。那么，如何简化客户程序与子系统之间的交互接口？如何将复杂系统的内部子系统与客户程序之间的依赖解耦？

（一）外观(Facade)模式 

public class Class1 {

public void method1(){

….

}

}

public class Class2 {

public void method2(){

….

}

}

public class Class3 {

public void method3(){

….

}

}

public class Class4 {

public void method4(){

….

}

}　　

假如客户程序要使用Class1、Class2、Class4完成一项业务功能，使用Class3、Class1完成另一项业务功能。

public class ClientNoFacade {

public void methodA() {//完成第一项业务功能

Class1 c1 = new Class1();

c1.method1();

Class2 c2 = new Class2();

c2.method2();

Class4 c4 = new Class4();

c4.method4();

}

public void methodB() {//完成第二项业务功能

Class3 c3 = new Class3();

c3.method3();

Class1 c1 = new Class1();

c1.method1(); }

}

（二）装饰器（Decorator）模式 

问题提出：在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？

考虑场景：

星巴克的分店几乎开遍世界各地。它们提供了各式各样的美味咖啡：爱尔兰咖啡、蓝山咖啡、卡布基诺、雀巢。每样咖啡都有自己的描述属性和收费行为。另外它们还提供各种配料：奶、砂糖、冰块、豆浆。不同的咖啡加入不同的配料计算的价格是不一样的。

如何设计？

用继承的方式实现简直是垃圾。

我们换一种思路：

现在用户点了一杯爱尔兰双倍牛奶咖啡，我们要做的是：

创建一个爱尔兰咖啡对象

用奶装饰它

再用奶装饰它

调用cost()方法，并依赖委托将配料的价格计算进去

代码实现：

//咖啡接口

package com.lovo.decoretor;

public interface Coffee {

海外公司注册、海外银行开户、跨境平台代入驻、VAT、EPR等知识和在线办理：https://www.xlkjsw.com

原标题：结构型设计模式

关键词：设计模式