Fatory Template Stategy --Head First Design Pattern读书笔记(三)

     虽然最近项目比较紧，但是仍坚持每天看几页Head First Design Pattern（short for HFDP），可以说是受益良多，刚刚看过Template Pattern，其中有一个特殊的环节就是FireSide Chat（HFDP的特色，没有新的Pattern讲述完毕，就会拿出类似的Patterns做对话，相当的不错）。这一次是Template vs Strategy compare methods。而factory 也和template也有很大相似的地方

    先分别说：

    一、Template method Patten  -- Encapsulating Algorithms

    这是我们最为熟悉和常用的一个设计模式，特别是用于框架的构建中，Template可谓功不可没，最为鲜明的例子：Struts。Template Method Pattern defines the skeleton of an algorithm in a method,deferring some steps to subclasses.Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

    一出现了Struts字样，就会发现Template method 一下就亲切了不少（其实这样说并不准确，实际上是Servlet实现了这一模式，而Struts的ActionServlet就是一个标准的Servlet实现），这样在我们平时的工作过程中，Template一下变得无处不在，不管什么项目，只要上点规模，肯定是要写个基础算法的基类，要不不行就上框架，OK，你已经在使用Template method pattern了，还有HFDP中还告诉我们java.io的read()方法 Array的sort() JFrame Applet都活跃着Template的影子，也就是说有一个固定的算法、一些可复用的方法这就构成了一个Template。Template是实现了经典好莱坞原则Don't call me,i'll call you的最佳范例，在好莱坞原则下，允许low-level component将自己hook到一个系统中，并且有High-level component决定他们什么时候被使用和怎样被使用。

    二、Strategy method pattern

    做为HFDP的开篇模式，Strategy的任务似乎更多一些，不但要让读者更为清晰的认识到使用模式的作用和必要性，还要介绍若干基本问题，而其通过几只不同的鸭子来阐述这一模式读者来说显得更生动而印象深刻。

     所以在认识Strategy的过程中我们首先认识的是3个OO design Principle

     1.Identify the aspects of your application that vary and separate them from what stays the same 鸭子是会变的，它们今天会叫、明天可能就会飞，它们会变成怎样我们不知道，但是我们有了这个设计原则就你要变就分开变，怎么变我们也不怕不怕。

    2.Program to an interface, not an implementation 最典型的就是Java的上溯造型了，看Think in Java最先学到的就是这个。

    3.Favor composition over inheritance 看来这第一章的信息量真的是大哦，composition，这里就引出了一个OO的两个基础模式composition和aggregation，于是去google，发现了这个：http://www.visualcase.com/kbase/associations.htm，重新理解下assosiation,compostion,aggregation之间的关系和区别。下面介绍了这些东西，猛然发现现在写文字也有职业病的困扰，这种介绍方式很像一个内部类的实现 ：（。明白了composition，这个原则就很清晰，慎用继承而使用composition。3个原则加在一起，Strategy的雏形也就差不多了：Strategy模式将可能会变化的部分封装起来与其他对象分离，并使用接口来调用他们而不去关心具体实现，这个过程都不是继承而来而是组合了所有接口。

     assosiation表明对象和对象之间有关系，学生去学校读书、学生选择课程，学生和学校、课程之间就有了关系。每个对象被称为roles，每个roles都由name、multiplicity、navigability、type几个属性构成

     Multiplicity:指定roles之间有多少对象可以参与到这个relationship中来，学校有多个学生，而学生只有一个学校。

     Navigability:每个roles都有arrow（在UML关系图中）指定他们的Navigability，展示classes在关联关系中维护关系的职责，可以通过学校知道有什么学生在学校读书，也就是defined by the navigability of the assosiation。

     type:可以有三种：assosiation,composition,aggregation，

          A.assosiation就是上面说到的关系

          B.composition 指明对象的从属关系，多边形包括多个点，多边形不在了，点也不复存在。

          C.aggregation 和composition类似，也表示对象的从属关系，但是没有composition那么严格，订单是包含多个产品，但是订单不存在产品却仍然存在。

     经历了3个设计原则的介绍，才把这个Strategy引出来，足见Strategy有多牛：The Strategy Method Pattern defines a family of algorithms,encasulates each one,and makes them interchageable.Strategy lets the algorithm vary independently from clients that use it.

     最常见的例子：Spring的DI，在使用一个Spring的Bean的时候就是先来个composition+setter method。

    三、Factory

     已经在我的上一篇读书笔记中提到很多了，所以这里就不详细说，Factory就是定义了对象构建的超类。但是和本文有关的是Abstract Factory，它不但构建了对象，还在构建的同时定义了一些固定的算法。

     比较：Template、Stategy、Factory

     狂多的东西都需要比较着来看，刚是合成、聚合和关联比较，现在是它们3个，真的很乱，特别是Factory还经常和Template混用，但是还是有些差别，Template比较单纯，仅仅是定义了算法的过程，而且是单纯的继承，Abstract Factory是指定了一定的算法去构建对象。

     Template和Strategy，个人认为，他们的比较就可以想Struts1和Struts2（webwork2）比较一样，一个使用了继承，一个使用了接口，这样对Template可能不公平，因为Struts令人诟病很深的就是这个继承，但是它仍然那么有生命力，Struts的ActionServlet定义了一个完成doget()请求的处理方式，也就是这个处理方式算法的骨架，然后由我们去实现具体的不同的业务逻辑，并且Template模式中子类是可以任意使用父类中的公共方法的，减少了代码重复。而WebWork的execution就是那么一个接口，如何实现你说了算，也就是那个封装和分离可能会变化的东西的原则，Webwork允许使用它的客户端来决定算法的变化。