下面全是个人理解。
Head First 第一章中讲的策略模式，我觉得是所有设计 模式中最基本的。
它提到了几个设计原则：都是我们平常编程中用到的。
1：将应用中变化之处和，不需要变化之处分离出来。这其实就很类似，封装的定义；
2：面向接口编程，而不是面向实现编程。想想我们在做web项目时，servie层，以及dao层，都是面向接口编程的，为的就是如果换掉数据库实现，那么在action层，我们就不需要更改代码了。
3：少用继承，多用组合。我们在做web项目时，service实现中，包含有dao的引用 ，其实就是组合。而且这种组合是高内聚，低耦合的。因为我们可以在运行时，指定特定的dao实现。这也是一种面向接口编程。
Head First 第一章针对Duck（鸭子）类 做了一个探讨。
Duck 书中定义的是抽象类，它有quack() 呱呱叫的方法，以及swim() 游泳的方法，还有一个抽象方法display() 外观方法。每种鸭子，都继承Duck类，自己实现display方法。
需求1：现在在Duck中增加一个方法fly()方法，由于 使用的继承，那么所有实现了Duck的子类 ，都有fly方法，就是会飞。但是问题来了，由于使用的是继承，会导致有些 不会飞的鸭子也拥有这个方法，有的人说，会飞就会嘛，有什么 关系，但是 你自己不觉得很怪吗？还有人觉得，我让不会飞的鸭子重写fly()方法，让它什么 都不做不就可以了吗？咋一想，好像是这么一回事，但是，如果有这么 一种鸭子，不会飞也不会叫还不会游泳，那么 你完蛋了，这个时候，你要检查所有的子类了，看看它们的所有方法，是否满足条件了、
所以继承带来的问题就是，子类继承了不必要的一些行为。
这个时候，我想要了接口，把鸭子的每种行为定义成一个接口，让那么需要有这些行为的鸭子去实现它，就可以了。哎，仔细想想，好像可以。
需求2：假如有三个子类分别实现了Duck，按照上面的想法，定义一个fly方法，quack()，swim()。那么这三个子类，如果三个子类fly,swim,quack的实现都是一样，那么 这样 代码是不是重复写了很多呀！！现在只是三个子类，如果30个呢，想想。
需求3：讲到这里，Head First 讲到了最后的解决方案，其实也是用到了接口，只是和上面不一样，它是定义一组接口行为，只是它由一组专门实现接口行为的类来实现，而不是由鸭子类来实现，我们只需要在Duck类中定义一些鸭子类的行为，具体的实现，在运行时，自己定义。这样，即使再增加一些行为，也只需要在Duck类中定义这些行为，具体的实现，就不关鸭子的事情了。