摘要: 原创作品，可以转载，但是请标注出处地址：http://www.cnblogs.com/V1haoge/p/6508967.html

　　之前认真学习了Java设计模式中的四大接口型模式，分别为：适配器模式（Adapter）、外观模式（Facade）、合成模式（Composite）、桥接模式（Bridge）。

1、在此处再温习一下四种设计模式：

（1）适配器模式：

　　我们能够访问的类中不存在我们要访问的内容时，就可以使用这个适配器模式，当然就类而言，其实不存在什么不能被访问，这里的不能访问都是人为的制约，规则的限制。

　　最为常见的就是在常规项目中使用的MVC分层模式，尤其在SpringMVC中体现的淋漓尽致：我们的请求来到SpringMVC的核心Servlet（DispatcherServlet）之后，由其进行请求分发，找寻合适的控制器（Controller），一般控制器是不会进行任何的业务处理的，它的作用就是用来接收请求与返回响应，而具体的请求与响应的处理则是在业务层（Service层）实现。

　　这样请求的目的很明确，就是要进行业务处理，而接收请求的控制器被人为（规则）限制不允许内部出现任何业务代码，怎么办？将其当做一个适配器来处理，使用组合的方式来控制器所在类中引用业务类（接口指向实现类），然后在控制器方法中调用能够完成请求目的的一个或者若干业务层类中的方法来进行业务处理，这正是适配器模式的一种典型应用。

　　请参考《Java设计模式之《适配器模式》及应用场景》一文

（2）外观模式：

　　外观也就是脸面、门脸，并不是说我们一定要使用外观，而是使用外观可以有诸多好处，它能够屏蔽系统复杂性，而且如果对系统功能的实现进行优化或更改，只需要对外观类进行简单的更新即可，而不会影响到使用这个系统的其他系统，这是外观类最重要的功能。

　　在这里我突然想到，上面举的例子中，控制器调用业务层实现类来完成具体的业务处理，从某种角度来看，同样也是外观模式的一种应用：控制器类针对整个网站业务系统而言何尝不是一个外观类的存在，外部请求来到系统后台，直面的正是这些控制器类，而不是复杂的业务处理类，在控制器中通过调用业务类方法的方式来为外部请求提供服务，这样整个复杂的后台业务系统被接口屏蔽，请求者不必关心自己要调用哪个业务类来实现自己的请求，而是有特定的控制器来完成这个内部调用。当我们对业务实现方法进行修正或更新时，只需要在控制器中稍作修改即可，整个请求毫无影响，对它而言未发生任何改变。

　　只是突然想到一点：我记得在外观模式中有这样的描述，外观类对系统并不是真正的屏蔽，其他系统任然可以通过直接调用系统内部的方法来完成功能，只是较为复杂罢了，这在SpringMVC中好像无法达成，因为SpringMVC被设计成为接口匹配方式来寻找控制器，也就是说请求来临只能找控制器，是无法直接调用业务实现类的，也许通过一些复杂的方式可能达到。

　　请参考《Java设计模式之《外观模式》及应用场景》一文

（3）合成模式：

　　有别于之前和之后要谈及到的模式，我认为合成模式较为狭隘，是指应用范围较为狭隘，好像主要针对的就是树形结构而言，如文件目录、多级目录结构等。

　　使用合成模式的目的并不是组合（即将下一级包含在上一级中），而在于一视同仁这一点。

　　何为一视同仁？简单的说就是将树形结构的两种形式一概而论，将目录结构的文件与目录一概而论，而不是分而论之。

　　如果将两者一视同仁，那么就能将二者抽象为一个概念（通常应该是用抽象类来表述），然后我们再针对二者分开进行抽象的继承实现，具体的区分二者，这样做，好似比原本就分而论之的结构要复杂，其实不然，我们使用抽象后，二者被概括为一个概念，这样我们在使用的时候，就可以使用同一个接口来进行实现（Java中的多态：抽象类指向实现类），具体的实现不必在代码中指定，而是自动根据情况来完成。这样不必再针对二者分开进行显式调用，简化了代码。

　　请参考《Java设计模式之《桥接模式》及应用场景》一文

（4）桥接模式：

　　以前诸多文章都未能在博客园首页留住，但这篇文章《Java设计模式之《桥接模式》及应用场景》尽然入了编辑的眼，进而被达内科技发布到了《今日头条》上，说明这篇文章还是不错的。

　　说道桥接模式，又称桥梁模式，望文生义，就是一座桥。这是一座接口桥。

　　查阅诸多文献，说道桥接模式就是将抽象与实现解耦，说实在话，不懂！因为这句话本身就抽象至极，谈何理解！

　　其实此处的抽象指的是调用方的抽象类实现，实现指的是被调用方的接口实现，这里谈及到两个实现，正是我们常见的实现：就是通过继承的方式来实现抽象类，通过实现的方式来实现接口，无外乎如此。

　　再谈谈解耦，这里的解耦也很好理解，就是解除直接耦合，什么样式直接耦合呢，很简单，通过继承类的方式实现的功能就是直接耦合，这样的耦合导致修改和扩展将会极为麻烦，这也正是解耦的目的所在。

　　再谈谈如何解耦，这里涉及到的双方就是调用者与被调用者，如果通过继承的方式来进行虽然符合Java继承规则，但耦合性太大，不易双方扩展，这样在二者之间架设一道桥梁，将二者的那种耦合隔开，通过中间桥来进行连接，这样一来，双方的扩展不再对对方产生任何影响，可以任意发展。

　　那么如何来架设这道桥梁呢？

　　很简单，使用接口与抽象类这两个神器，我们为被调用者创建一个接口，而这个接口就是那座桥，其实我们将桥与被调用者绑定在一起了，而针对调用者，我们创建一个抽象类（为何此处是抽象类，而不是接口呢？因为我们要在这个抽象类内部引用桥接口，而接口中一般是没有属性的<只有静态常量>），故使用抽象类），在其中引用桥接口，并创建合适的方法，用于被继承类实现来进行扩展。

　　如此一来，目的达成，不明白的，请看《Java设计模式之《桥接模式》及应用场景》一文。

2、接口类型

　　上述的四种设计模式均涉及到了接口，此处的接口并不是Interface这个意思，而是一种“对外”或“被调用”的意思，还有一层屏蔽的意思。

　　接口类型多是使用接口来屏蔽具体的实现，为调用者提供一个友好的界面（接触口）。

（理解尚浅，待补充）

Java设计模式之《组合模式》及应用场景

Java设计模式之接口型模式总结