【大话设计】之个别模式总结（一）

          验收的过程中，只能用四个字来形容，那就是一塌糊涂。。。。具体细节就不说了，反正现在我也释然了，哇哈哈。师傅告诉我重点看几个模式，最近可能要用，其他的模式以后都还会碰到，不要再在上边用这么长时间了，毕竟我也延期了好几次了，于是我的大话设计就这么结束项目了，虽然结束了，但是我的学习还没有停止，下边是我对策略模式、模板方法模式还有外观模式的一个总结。。。。

          【策略模式】

           简单模式工厂的实现可以在增加一些新的算法的时候可以直接增加算法类。然后在简单工厂中添加分枝语句。但是这个模式只是解决对象的创建问题，而且由于工厂本身包括了所有的收费方式，商场是可能经常性的更改打折额度还有返利额度，每次维护或扩展收费方式都要改动这个工厂。以致代码要重新部署，这真的是很糟糕的方式，所以这时出现了策略模式。。。。他们的结构图是这样的。。。

                所谓的策略模式就是“定义了算法家族，分别封装起来，让他们之间可以相互转换，此模式让算法的变化不会影响到使用算法的客户。。。。。”封装变化点是面向对象的一种很重要的思维方式。。。其实在图中我们也可以看得出来。简单工厂模式我如要让客户端认识两个类，那就是cashsuper 和  cashfactory  而策略模式就只需要让客户端认识一个context类就可以了。。。我的理解其实就是无论哪种策略，context类中通过一种调用方式，只不过调用的策略不一样。我们只需要从context中调取就可以了。。。。。。这使得具体的算法彻底与客户端分离，连算法的父类cashcontext都不让客户端认识了。。。

                “策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同。他可以以相同的方法调用所有的算法，减少了各种算法类与使用算法类之间的耦合。。。策略模式的strategy类层次为context定义了一系列的可供重用的算法和行为，继承有助于吸取出这些算法类之间的耦合。。另外一个策略模式简化了单元测试，因为每个算法都有自己类。可以通过自己的接扩单独测试。。。。（这里我想到了，，机房收费系统中不同的用户有不同的收费方式。。。这里在重构的时候是不是要用到策略模式。。。嘿嘿，期待你。。。）

     【模板方法模式】

             模板方法模式，，，用我自己的理解其实就是，小学的时候，老师或者总是叫一个学生在黑板上抄一些题，让同学们做。。。抄完之后我们最希望听的就是老师说一句，不用抄题目，直接写答案就行了。。。。。那个时候就会觉得是最最值得我们欢喜的事情。。。模板方法模式就是，将我们需要做的那些重复做的事情放到一个地方，就是所谓的抽象出来，，我们需要做的就是那些互不相同的事情。。。模板方法我觉得其实就是我们将一个算法写成函数放在那，可以用的时候直接拿过来用而不用重复的去屑那些过程。。其实是我们最常用的一种方法。。。。下边就是模板方法模式的结构图。。。。

      我们什么时候要用模板方法模式呢。。当然是要想要偷懒的时候，当我们要完成在某一细节层次一致的一个过程或一系列步骤，但其个别步骤在更详细的层次上的实现可能不同时，我们通常考虑用模板方法模式来处理。。。模板方法模式，定义一个操作中的算法的骨架，而将一些步骤拖延到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。。。。。所谓的延迟到子类，就是我们例子中在答案那里加一个虚方法answer()。。。。模板方法模式是通过把不变的行为搬移到超类，去除子类中的重复代码，来体现它的优势。。。。它提供了一个很好的代码复用平台。。。当不变和可变的行为在方法的子类实现中混合在一起时，不变的行为就会在子类中重复出现，我们通过模板方法模式把这些行为搬移到单一的地方，这样就帮助子类拜托重复的不变行为的纠缠。。。。。

      【外观模式】

         外观模式中大鸟用一个市民买股票还是买基金的例子讲述的。在市民买股票的时候，经常是由于对股票不会那么精通，所以总是有很大的亏本风险。但是如果直接从基金会买基金的话，虽然不会像是买自己买对了股票一样赚的那么多，但是最起码这样会很稳定，不会像自己买股票的时候亏损特别大，这是什么原因呢，当市民买股票的时候，面对如此多的股票，风险是很大的，这就要求市民要对众多股票多非常的了解，才有可能买到一支好的股票。但是这样的要求对于每个市民来说就很困难了。这么多股票，我们怎么样才能了解这么多呢。所以说这样的话市民跟股票间的耦合度就太大了。如果交给基金会呢？基金会是一支对股票比较有经验的队伍，当我们将钱交给基金会的时候，他们将零碎的钱都收集起来，凭着经验会买很多支比较有希望的股票，这样，即便是有几支股票赔了也不会是影响大局的，因为多数股票是赚钱的（通常都会是这样）。这样就会使得市民能够算是稳定的赚钱。。。这种机制就是外观模式，它降低了股民对股票的耦合度，甚至股民可以对股票一无所知，直接将钱交给基金会就能等着拿钱了。。。所有的事情都只交给基金会就好了。。。。下面是股民买股票和将钱交给基金会的结构图。。。

              外观模式，以我个人意见来看，其实跟粗略模式是比较似的，都是减少了客户端与实际逻辑和数据的耦合度，客户端不需要知道数据库中的那些事情，只要在页面点击一下查询，自己的信息就会显示出来，而这些都是业务逻辑层帮忙调取的。。。降低了它们之间的耦合性。。。最近在学习三层，数据访问层和业务逻辑层、业务逻辑层和表示层都建立外观facade，这样就可以为复杂的子系统提供一个简单的借口，使得耦合大大降低，其次在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，大多数模式使用时也都会产生很多很小的类，这本是好事，但是也给外部调用它们的用户程序带来使用上的困难。增加外观facade可以提供一个简单的接口，减少他们之间的依赖，第三，在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了。但因为它包含非常重要的功能，新的需求开发必须要依赖它，此时用外观模式也是非常合适的。。。你可以为新系统开发一个外观facade类，来提供涉及粗糙或高度复杂的遗留代码的比较清晰的简单接口，让新系统与facade对象交互，facade与遗留代码交互所有复杂的工作。下面是模式图。

       【总结】当我再次看这几个模式的时候，真的感觉比第二遍要清晰多了，这更加证明我想要一遍学会的思想是极其错误的了。。。。书读百遍，其义自现。。。