您的位置：首页 > 其它

【机房收费系统合作版】——再看外观模式

2014-12-06 19:49 405 查看

前言：这次合作版机房，在小伙伴们的商量下，决定使用外观模式。由于个人版的时候，因为各种原因，未能使用这一模式。现在，借着这次机会，重新认识一下这位故友。

我们先看下边的一张图：

这张图大概意思就是：射雕中的这三个人想喝茶。A图呢，是自己泡茶。茶具、茶叶什么都得自己准备，比较繁琐；B图呢，是去茶馆喝茶，只要告诉服务员喝什么茶就行，其他一概不用理会。

其实，简单一个喝茶，中间就包含着我们今天要说的：外观模式。

概述：

我们在架构设计的过程中，一次的功能访问可能需要同时调用多个对象，那么如果我们在调用的时候，能够在应用程序中一次就能完成所有同时需要调用的对象，就会给我们带来很大的方便。这时，外观模式就是很好的借鉴。

外观模式，它通过引入一个外观角色来简化客户端与子系统之间的交互，为复杂的子系统调用提供一个统一的入口，降低子系统与客户端的耦合度，且客户端调用非常方便。

定义：

外观模式：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

结构

外观模式的主要目的在于降低系统的复杂程度，它通过引入一个外观角色来简化客户端与子系统之间的交互，为复杂的子系统调用提供一个统一的入口，使子系统与客户端的耦合度降低。外观模式并不给系统增加任何新功能，它仅仅是简化调用接口。

优缺点

优点：

1、它对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少。

2、它实现了子系统与客户端之间的松耦合关系，这使得子系统的变化不会影响到调用它的客户端，只需要调整外观类即可。

3、一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。

缺点：

1、不能很好的限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制，则减少了可变性和灵活性。

2、如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则。

适用场景：

1、当要为访问一系列复杂的子系统提供一个简单入口时，可以使用外观模式

2、客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。

3、在层次化结构（三层架构）中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，例如：U层和B层。通过外观类降低联系，这样，降低了层与层之间的耦合度。

拓展：

在第一遍做机房的时候，大多数人的架构图都应该是这样画的吧

但我们在这次的机房合作中，架构图如下：

相比上边那张，我们的多了一条线。在U层和B层之间，有些交互需要调用B层中的好几个类，但有些只需要调用一个。所以，可以将复杂的操作，通过外观来进行整合；而相对简单的，直接调用，也是未尝不可的。

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航