浅读《大话设计模式》————2、商场促销——策略模式

从本章我首先得到的第一个信息是：策略模式的问题，简单工厂模式也能实现；推而广之，同一个问题，可能许多模式都能实现，但是这里总存在一个更优的问题。至于真正用那个模式，就是C++之父的那句话了：需要经验智慧了。

第二个马上引出问题的结论：“面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类”。这一句，我觉得是最深刻的道出类设计原则的精辟之语。意思：第一、类并非越多越好，设计一个类是有价值有意义的：是为了封装（简单工厂的那个工厂类就是一个纯封装作用的类，但大多数情况建立一个类还需要别的理由，可能简单工厂属于一个特例）。第二、何时设计类，当处理的看似一些杂乱无章的东西具有相同的属性和功能时，就有必要创建类，因为，用对象实现某些功能在可维护可复用等方面要比直接的函数过程似的编程要好得多。以上两点，可能就是怎样将实际问题抽象成类的秘诀了！

当时我看到现金收费工厂类时，我心里已经为“菜鸟”拍案叫绝了。他的学习能力好强呀！⊙﹏⊙b汗！然而，大鸟后面的那些一针见血的话同时也让我进入了沉思。。。当我们发现自己好不容易掌握了一样东西，我们似乎认为自己学得是易筋经，以后就可以以此横扫天下了，但是还没出走出山门，就被路上的山贼给鄙视了。。。这可能是少林寺有了易筋经还要有72绝技的原因。。。

被鄙视的原因：简单工厂模式只是解决了对象的创建问题，工厂需要包括所有的对象的创建，如果对象形式经常变化，就需要经常改动工厂，以致代码重新编译。结论：面对对象形式不断变化的情况，应该采取比工厂模式更好的武功！

幸亏这本秘籍并不难找：策略模式---它定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。[DP]

问题：在2.7策略模式解析之上的部分，作者最终利用的方法是将策略模式与简单工厂模式结合起来用，当然与之对比的简单工厂模式显然稍逊一筹。但是我个人的观点是：此处采用单纯的策略模式而不是两者结合更好。即2.5的实现，因为我认为：加入工厂模式就同时将本问题中工厂模式的问题带进来了，策略模式的Context需要经常重新编译；而相对于算法经常变化的情况，将算法选择交给客户端应该还是可取的。现对而言，我认为前者更好操作。不够，当我读到本章最后时，我才又一次发现我的孤陋寡闻！还有更好的招！后面再学。

策略模式的关键之一----------Context:“策略模式的Strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公共功能”。

策略模式理解核心-------------“策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性[DPE]”。

在基本的策略模式中，选择所用的具体实现的职责由客户端对象承担，并转给策略模式的Context对象[DPE]。这是策略模式本身纯粹的定义，所以，“选择所用最终怎样处理”还有很多文章可做！

“反射反射，程序员的快乐”，我以前又从来没有听过。。。怎么让我想起了慕容家族的绝技-----斗转星移了呢？我的神呀？