设计模式-外观模式

分析现实中这样一个现象，自己泡茶喝茶和去茶馆喝茶的区别是什么呢？自己泡茶的话，自己要准备个各种材料，然后用这种材料泡茶，而去饭店里面，则只需要告诉服务员自己需要什么茶，服务员则帮助你把茶准备好，然后送给你就可以。

软件开发中也有这样一种现象，这样一个文件加密系统，它分为三部分，分别是文件读取，文件加密，问价存取，然后不同的软件都可以运用这样一个加密系统。如果我们按照自己泡茶的生活现象来完成此操作。可以有这样的代码实现，首先我们要弄明白面向对象设计的理念，两个对象之间如果要有关联，则可以通过构造注入，设置注入，借口注入方式来实现彼此对象的引用，当然也可以直接在对象里面创建引用的对象，这样实现了对象之间的关联关系，如果要用关联对象的一些行为，在面向对象里面就是调用方法，来实现这样一种行为。仿照做茶的过程，首先我们要读取文件，那么可以在使用的系统（A）中创建读取文件的对象类，开始读取文件，也就是开始泡茶第一步，则就是调用读取文件类的方法，加密文件，存取文件都是类似的实现，这种设计方法，存在以下一些问题。当然，所有使用此种加密系统的功能都是类似的写法。

第一：许多系统都是相同的代码，造成维护的不方便；

第二：如果我先要更改此加密系统的一种加密方法，则所有使用此系统的其他系统，都需要更改代码，违反了开闭原则，也造成维护的复杂度

在此种需求下，实现了外观模式，即引入了服务员角色。

这个服务员角色，只需要知道你想要什么样的茶，也就是需要对那些文件进行操作，他就可以自己完成一些功能，系统则唔需要关注具体的实现，要用服务员，当然在使用系统中要有服务员角色的引用，有了服务员还不行，我还要告诉服务员，我读取那些文件也就是喝什么茶，所以可以调用服务员类的一个方法，把我想要实现的东西给他，这样他就可以继续执行这个泡茶的过程，在此中模式下，将客户端与实现通过服务员角色解耦，增加了系统的可维护性。

在此深入分析，如果我们想换服务员，为了保证在客户端代码的开闭原则，可以这样分析，无非是两部，第一个是叫到确定服务员，然后给服务元信息，首先是叫到服务员，代码来说就是在系统中创建服务员对象，要想不更该代码，此时就是抽象类的用处了，传递消息，为了代码一致性，可以在抽象类中创建方法，这个方法就是传递消息的方法，然后所有的服务员都是做这个方法来接受消息，这样就实现了代码的一致性，但是问题又来了，引入抽象类，可以保证执行的方法不变，但是我还是要确定一个具体的服务员啊，也就是创建具体的对象，因为抽象对象是不具有行为操作的。确实如此，要实现这样功能，就是引入配置文件，用配置文件来决定具体的服务员类，这样就可以在不更改业务系统服务端代码的情况下，实现具体服务员的更改。

此种模式，要注意与工厂模式区别开来，工厂模式最终只是拿出了对象，但是客户端代码要与具体的实现还是有一定的关联关系，但是此外观模式，就是引入了外观对象，可以让客户端不至于与具体的实现来联系，增加维护性。

总之，设计模式是很深的东西，这些都是表面的一些写法，所以要联系现实生活的例子然后尝试用代码的方式来实现，因为软件技术为生活服务的。对象之间的关联，通过注入的方式实现，对象之间的动作，通过方法实现。增加代码一致性，可以引入抽象类和抽象方法。