金融危机中如何通过外观模式挣钱？

第四章　金融危机股票还挣钱？——外观模式

4.1　金融危机股票还挣钱？

时间：12月17日　　地点：大B房间　　人物：大B，小A

小A：“大B，你今年有炒股票吗？”

大B：“有啊！买了一些。”

大B很奇怪为什么小A突然问这个问题：“怎么会这么问哩？”

小A：“我们班上好多同学都炒了，不过大部份都还是新手，都不太懂的。”

大B：“那他们的股票今年都怎么样呐？”

小A：“都亏了，今年什么形式呐！”

大B：“今年很多炒股的人都亏了。”

小A：“他们都是刚入市不久的，什么都不懂。对了，好像有个还可以，赚了不少钱，具体是怎么样也不太清楚。只是天天下课后，在教室里，那些买了股票的同学就会聚在一起讨论今天股市的走势情况，有的边上课还边有手机上网关注股市哩！”

大B：“呵呵……都是新股民呐，其实按今年的行情买股票是应该很小心的。”

小A：“嘿嘿！都是学生，买了一点股票，天天在关心，不过也是，自己的买了股票，就今年的行式，谁能不关心呐！特别是前段时间，从6000多点降到了2000点以下。几多人伤心，几多人愁呐！”

大B：“现在的学生是有不少在炒股票的。不过应该买得都不多吧？”

小A：“是啊。大部份都不多的。都还只是学生嘛！对了，师兄，你的股票今年走势如何啊？”

大B：“我的啊？今年还好，今年还是挣钱的。”

小A：“是么？呀！师兄，你真历害！”

大B：“我只是炒短线，平时对股票也比较在研究，刚好上次跌的时候我的原来买的卖了，后来一直跌，我都是小心地进仓，挣得不多，但还算是可以的。你有没有买股票呐？”

小A：“股票我是没有买，买了一些基金。唉，我也是个新手，想着不会炒股，就买个基金算了，结果遇到今年形式不好，还是亏得只有一半了。”

大B：“基金？挺好啊！它将投资者分散的资金集中起来，交由专业的经理人进行管理，投资于股票，债券，外汇等领域。而基金投资的收益师持有都所有。管理机构只收取一定比例的托管费用。不过今年金融风暴横扫全球，全世界经济受到严重影响。”

小A：“是啊，所以现在也没办法。师兄，你怎么在现在这样金融危机股票还挣钱？”

大B：“因为我时时都在关注时事，而且我主要了解股票的各种信息，结合现今时事预测它的未来。还要买入和卖出的时机合适，这是很难帮到的。”

小A：“投资买股票，做不好的原因和软件开发娄中的什么类似？而投资者买基金，基金经理人拿这些钱去投资，然后获利后分给大家，这体现了什么？”

大B：“由于大多投资者对众多股票的联系太多，反而不利于股票操作，这在软件中叫耦合性过高。而基金，是众多投资者只和基金打交道，只关心基金的上涨和下跌就可以了，而实际在操作的是基金经理人。”

4.2　外观模式意图

股市有风险入市须小心啊！这就是外观模式。

大B：“师弟，你现在明白什么是外观模式没有啊？”

小A：“明白了。外观模式定义了一个将子系统的一组接口集成在一起的高层接口，以提供一个一致的界面。通过这个界面，其他系统可以方便地调用子系统中的功能，而忽略子系统内部发生的变化。”

大B：“是的。”

4.3　使用场合

大B：“说说在什么情况下可以使用它吧！”(www.xing528.com)

小A：“1、为一个比较复杂的子系统提供一个简单的接口。2、将客户程序与子系统的实现部分分离，提高子系统的独立性和可移植性。3、简化子系统间的依赖关系。”

大B：“外观模式（Facade pattern）涉及到子系统的一些类。所谓子系统，是为提供一系列相关的特征（功能）而紧密关联的一组类。例如，一个Account类、Address类和CreditCard类相互关联，成为子系统的一部分，提供在线客户的特征。在真实的应用系统中，一个子系统可能由很多类组成。子系统的客户为了它们的需要，需要和子系统中的一些类进行交互。客户和子系统的类进行直接的交互会导致客户端对象和子系统（Figure1）之间高度耦合。任何的类似于对子系统中类的接口的修改，会对依赖于它的所有的客户类造成影响。如图4-1所示”

图4-1　外观模式

小A：“这样说来，外观模式（Facade pattern）很适用于在上述情况。”

大B：“是啊。外观模式（Facade pattern）为子系统提供了一个更高层次、更简单的接口，从而降低了子系统的复杂度和依赖。这使得子系统更易于使用和管理。外观是一个能为子系统和客户提供简单接口的类。当正确的应用外观，客户不再直接和子系统中的类交互，而是与外观交互。外观承担与子系统中类交互的责任。实际上，外观是子系统与客户的接口，这样外观模式降低了子系统和客户的耦合度(如图4-2所示)。”

图4-2　外观模式降低了子系统和客户的耦合度

大B：“从图4-2中我们可以看到：外观对象隔离了客户和子系统对象，从而降低了耦合度。当子系统中的类进行改变时，客户端不会像以前一样受到影响。尽管客户使用由外观提供的简单接口，但是当需要的时候，客户端还是可以视外观不存在，直接访问子系统中的底层次的接口。这种情况下，它们之间的依赖/耦合度和原来一样。”

4.4　例子

大B:“我给你举个例子来说明吧。”

小A：“嗯。好的。”

大B：“让我们建立一个应用：1、接受客户的详细资料（账户、地址和信用卡信息）2、验证输入的信息3、保存输入的信息到相应的文件中。这个应用有三个类：Account、Address和CreditCard。每一个类都有自己的验证和保存数据的方法。”

图4-3　验证并保存客户数据

大B：“建立一个客户AccountManager，它提供用户输入数据的用户界面。”

当客户AccountManage运行的时候，展示的用户接口如下：

图4-4　用户接口

大B：“为了验证和保存输入的数据，客户AccountManager需要：1、建立Account、Address和CreditCard对象。 2、用这些对象验证输入的数据3、用这些对象保存输入的数据。”

图4-5是对象间的交互顺序图：

图4-5　对象间的交互顺序图

大B：“在这个例子中应用外观模式是一个很好的设计，它可以降低客户和子系统组件（Address、Account和CreditCard）之间的耦合度。应用外观模式，定义一个外观类CustomerFacade (Figure6 and Listing5)。它为由客户数据处理类（Address、Account和CreditCard）所组成的子系统提供一个高层次的、简单的接口。 ”

图4-6　外观类

大B：“CustomerFacade类以saveCustomData方法的形式提供了业务层次上的服务。客户AccountManager不是直接和子系统的每一个组件交互，而是使用了由CustomFacade对象提供的验证和保存客户数据的更高层次、更简单的接口(如图4-7所示)。”

图4-7　验证和保存客户数据

大B：“在新的设计中，为了验证和保存客户数据，客户需要：1、建立或获得外观对象CustomFacade的一个实例。2、传递数据给CustomFacade实例进行验证和保存。3、调用CustomFacade实例上的saveCustomData方法。CustomFacade处理创建子系统中必要的对象并且调用这些对象上相应的验证、保存客户数据的方法这些细节问题。客户不再需要直接访问任何的子系统中的对象。”

图4-8展示了新的设计的消息流图：

图4-8　新的设计的消息流图

4.5　应用外观模式的注意事项

小A：“师兄，应用外观模式有哪些注意事项？”

大B：“应用外观模式要注意以下事项：1、在设计外观时，不需要增加额外的功能。2、不要从外观方法中返回子系统中的组件给客户。例如：有一个下面的方法：CreditCard getCreditCard() 会报漏子系统的细节给客户。应用就不能从应用外观模式中取得最大的好处。3、应用外观的目的是提供一个高层次的接口。因此，外观方法最适合提供特定的高层次的业务服务，而不是进行底层次的单独的业务执行。”

小A：“明白。我记住了。”