前言

本篇来学习下结构型模式的外观模式和装饰器模式。

外观模式

简介

外观模式隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。

简单的来说就是对外提供一个简单接口，隐藏实现的逻辑。比如常用电脑的电源键，我们只需按电源键，就可以让它启动或者关闭，无需知道它是怎么启动的(启动CPU、启动内存、启动硬盘)，怎么关闭的(关闭硬盘、关闭内存、关闭CPU)；

这里我们还是可以用电脑玩游戏的例子来外观模式进行简单的讲解。

电脑上有一些网络游戏，分别是DNF、LOL和WOW，我们只需双击电脑上的图标就可以启动并玩游戏了，无需关心游戏是怎么启动和运行的了。

需要实现的步骤如下:

建立游戏的接口；

建立LOL、DNF和WOW的类并实现游戏的接口；

定义一个外观类，提供给客户端调用。

调用外观类。

代码示例:

interface Game{

void play();

}

class DNF implements Game{

@Override

public void play() {

System.out.println("正在玩DNF...");

}

}

class LOL implements Game{

@Override

public void play() {

System.out.println("正在玩LOL...");

}

}

class WOW implements Game{

@Override

public void play() {

System.out.println("正在玩WOW...");

}

}

class Computer{

private Game dnf;

private Game lol;

private Game wow;

public Computer() {

dnf=new DNF();

lol=new LOL();

wow=new WOW();

}

public void playDNF(){

dnf.play();

}

public void playLOL(){

lol.play();

}

public void playWOW(){

wow.play();

}

}

public static void main(String[] args) {

Computer computer=new Computer();

computer.playDNF();

computer.playLOL();

computer.playWOW();

}

运行结果:

正在玩DNF...

正在玩LOL...

正在玩WOW...

在上述代码示例中，我们在想玩游戏的时候，只用实例化外观类调用其中的游戏方法即可，无需关心游戏是怎么启动和运行的。而且每个游戏之间也相互独立，互不影响，不会因为某个游戏玩不了导致其它的游戏也无法运行。其实感觉外观模式和我们平时使用接口很相像，都是对外提供接口，并不需要关心是如何实现的。

外观模式的优点:

降低了耦合，从某种方面来说也提升了安全性。

外观模式的缺点:

不符合开闭原则，不易更改。

使用场景      系统中有多个复杂的模块或者子系统的时候。

装饰器模式

简介

装饰器模式允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。

装饰器模式，顾名思义，也就是把某个东西进行装饰起来，让它可以提供一些额外的功能。比如对人进行装饰，做不同的事情的时候穿上不同的服装。比如穿上球衣是准备去打球，穿上泳衣是准备去游泳之类的。

装饰器模式可以动态地给一个对象添加一些额外的职责。

这里我们依旧用一个示例来进行说明。

在现在的玩具模型中，有两种模型很受欢迎，高达(GUNDAM)模型和扎古(MrGu)模型，在我们拼接模型的时候，一般都是先将模型拼接好，然后再来添加一些额外的配件，比如武器。在这里我们在拼接好高达(GUNDAM)模型和扎古(MrGu)模型之后，给它们装上各自的武器。

具体实现的步骤如下:

创建一个抽象构件的模型接口，有组装这个方法；

创建具体构件的类(GUNDAM类和MrGu类)，并实现上述的模型接口；

定义一个装饰器，用于接受客户端的请求，并根据客户端的请求进行相应的调用；

定义个具体实现装饰的类，用于给对象添加相应的功能。

代码示例:

interface Model{

void assemble();

}

class GUNDAM implements Model{

@Override

public void assemble() {

System.out.println("组装一个高达模型");

}

}

class MrGu implements Model{

@Override

public void assemble() {

System.out.println("组装一个扎古模型");

}

}

abstract class AddExtra implements Model{

protected Model model;

public AddExtra(Model model){

this.model=model;

}

public void assemble(){

model.assemble();

}

}

class LightSaber extends AddExtra{

public LightSaber(Model model) {

super(model);

}

public void assemble(){

model.assemble();

addLightSaber();

}

public void addLightSaber(){

System.out.println("添加光剑");

}

}

class RocketLauncher extends AddExtra{

public RocketLauncher(Model model) {

super(model);

}

public void assemble(){

model.assemble();

addRocketLauncher();

}

public void addRocketLauncher(){

System.out.println("添加火箭筒");

}

}

public static void main(String[] args) {

Model gundam=new GUNDAM();

Model mrgu=new MrGu();

gundam.assemble();

mrgu.assemble();

Model gModel=new LightSaber(new GUNDAM());

gModel.assemble();

Model mModel=new RocketLauncher(new MrGu());

mModel.assemble();

}

运行结果:

组装一个高达模型

组装一个扎古模型

组装一个高达模型

添加光剑

组装一个扎古模型

添加火箭筒

在上述的代码中，我们如果只想组装高达或这扎古的模型的话，可以直接实例化模型类，调用其中的方法即可。假若需要在组装模型的时候，添加一个武器，只需通过装饰器的类进行相应添加相应的功能即可。

通过这个示例，我们发现，在使用装饰器模式的试试，可以对一些类进行扩展，并且不影响之前的功能，提升了灵活度。

装饰器模式的优点:

装饰类和被装饰类可以独立发展，耦合度低，易于扩展，灵活方便。

装饰器模式的缺点:

过多的对某个类进行装饰，会增加复杂度。

使用场景 原型不变，动态增加一些功能的时候

写在最后：欢迎留言讨论，点“关注”，不迷路，加关注，持续更新！