我理解的JAVA策略模式Strategy Pattern,跟你有没有共鸣？是对是错？

我理解的JAVA策略模式Strategy Pattern（设计原则 多用组合，少用继承）
没有一定程序开发的经验，可能会看不懂，有开发经验的话，会跟偶有共鸣，有非常丰富的开发经验的话，会非常不屑，你是哪种啊，呵呵。

    * 世界上的一部分对象，被归结为一个类别，于是有了类

    * 但类中的对象都有细微的差别，包括特性(属性)和行为(方法)，于是有了接口和抽象类，并产生OO的三大特性:封装，继承，多态（有书上说四大特性，还包括抽象）

    * 类是对特性和行为的封装，接口和抽象类是体现差异化，通过继承来实现多态

    * JAVA中的类继承抽象类的缺陷在于，两个不同的子类可能有不同的行为,而都继承一个抽象类，则表现为，一个子类分明没有某一行为，但因为继承了抽象类，它必须实现这一抽象行为，却什么也不做，这不是一个好的策略。

    * 于是有了接口，同一类的不同子类因为有不同的行为，可以将所有子类共同的行为抽象出来，放在抽象父类中来继承，不同的行为在放在不同的接口中来实现，这样看来，貌似是一个很好的设计策略，其实仍有一个很大的缺陷，如果有20个子类同时具有某一接口的特性，那么这一特性要被实现20次，这将出现大量的重复设计。

    * 于是，策略模式闪亮登场。将这些被大量重复的行为剥离出来，另建一个对应于原类的“行为类”，并让原类拥有一个行为类的依赖，当调用原类的某一行为时，事实上是委托其依赖的行为类上的对应的方法。

    * 策略模式的好处在于，将子类中共同的行为剥离出来，放在行为类中，让子类动态的绑定行为类，多个子类具有相同的行为，就可以绑定用一个行为类，而不必全部实现某一接口。更重要的意义在于，这是一种松耦合的设计原则，采用了组合代替继承的方式。每个子类都可以动态的定制行为类

简单的说：
策略模式，就是将军定战略，指挥官定策略的过程，其中将军是调度类，指挥官是策略接口或抽象类，坦克指挥官是子类
模板方法模式，就是指挥官必须是将军，其他同上
两者面向的问题领域是一致的

指挥官必须是将军？ 坦克指挥官吧。
按你说的，模板模式就是一个简单的继承关系？

老觉得java里面抽象类的方法必须统统实现很无聊，习惯了C++编程，对这点很费解。不过后来学了接口和策略，发现java还是略胜一筹

这不是继承的缺陷，而是你设计的缺陷。你的设计本身就违反了LSP(子类必须能够替换父类)。

这是继承这种对象特性的缺陷。公鸭和母鸭都是鸭，公鸭当然能替换鸭了（子类必须能够替换父类），但公鸭没有下蛋的方法，母鸭有，可以通过设计比如采用策略模式来弥补。

    * JAVA中的类继承抽象类的缺陷在于，两个不同的子类可能有不同的行为,而都继承一个抽象类，则表现为，一个子类分明没有某一行为，但因为继承了抽象类，它必须实现这一抽象行为，却什么也不做，这不是一个好的策略。

   这个不是类继承的缺陷，而是设计问题，父类中的行为子类必须具有，否则这个父类设计上就有问题。

    * 于是有了接口，同一类的不同子类因为有不同的行为，可以将所有子类共同的行为抽象出来，放在抽象父类中来继承，不同的行为在放在不同的接口中来实现，这样看来，貌似是一个很好的设计策略，其实仍有一个很大的缺陷，如果有20个子类同时具有某一接口的特性，那么这一特性要被实现20次，这将出现大量的重复设计。

   这个又是一个设计问题，如果20个子类具有同一接口特征，这20个子类应再从同一个父类中派生

你设计错误了，鸭不能有下蛋的方法。下单有单独的下单nable的接口。

你搞错了。策略模式解决的是下什么蛋，怎么下单，不是下不下蛋的问题。

不就是函数指针么。