Head First设计模式 第一章阅读笔记

设计模式入门

策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

1. 当涉及“维护”时，为了“复用”(reuse)而使用继承，结局并不完美。
2. Java接口不具有实现代码，所以继承接口无法达到代码的复用。
3. 软件开发的一个不变真理：不管当初软件设计得多好，一段时间之后，总是需要成长与改变，否则软件就会“死亡”。
4. 即使是行为，也仍然可以有状态和方法。

利用继承来提供Duck的行为，会导致下列缺点

1. 代码在多个子类中重复；
2. 运行时的行为不容易改变；
3. 很难知道所有鸭子的全部行为；
4. 改变会牵一发动全身，造成其他鸭子不想要的改变。

设计原则

1. 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。把会变化的部分取出并“封装”起来，好让其他部分不会受到影响。代码变化引起的不经意后果变少，系统辩的更有弹性。
2. 针对接口编程，而不是针对实现编程。这样，不再需要知道行为的实现细节。“针对接口编程”真正的意思是“针对超类型(supertype)编程”
3. 多用组合，少用继承。使用组合建立系统具有很大的弹性，不仅可将算法族封装成类，更可以“在运动时动态地改变行为”，只要组合的行为对象符合正确的接口标准即可。

简单的多态例子

“针对实现编程”：

Dog d = new Dog();
d.bark();

声明变量"d"为Dog类型（是Animal的具体实现），会造成我们必须针对具体实现编码。
但是，“针对接口/超类型编程”做法会如下：

Animal animal = new Dog();
animal.makeSound();

我们知道该对象是狗，但是我们现在利用animal进多态的调用。
更棒的是，子类实例化的动作不在需要再代码中硬编码，例如new Dog()，而是“在运行时才指定具体实现的对象”。

a = getAnimal();
a.makeSound();

我们不知道实际的子类型是“什么”……我们只关心它知道如何正确地进行makeSound()的动作就够了。

实现鸭子的行为

在此，我们有两个接口，FlyBehavior和QuackBehavior，还有它们对应的类，负责实现具体的行为：
参考第13页图片。

这样的设计，可以让飞行和呱呱叫的动作被其他的对象复用，因为这些行为已经和鸭子类无关了。
我们可以新增一些行为，不会影响到既有的行为类，也不会影响“使用”到飞行行为的鸭子类。
这么一来，有了继承的“复用”好处，却没有继承所带来的包袱。

整合鸭子的行为

关键在于，鸭子现在会将飞行和呱呱叫的动作“委托”（delegate）别人处理，而不是使用定义在Duck类（或子类）内的呱呱叫和飞行方法。
做法：

1. 首先，在Duck类中”加入两个实例变量“，声明为接口类型（而不是具体类实现类型），每个鸭子对象都会动态地设置这些变量以在运行时引用正确的行为类型；
2. 
3. 

动态设定行为

在鸭子子类中通过“设定方法(setter method)”来设定鸭子的行为，而不是在鸭子的构造器内实例化。从此以后我们可以随时调用方法改变鸭子的行为。

要点

1. 知道OO基础，并不足以让你设计出良好的OO系统。
2. 良好的OO设计必须具备可复用、可扩充、可维护三个特性。
3. 模式可以让我们建造出具有良好OO设计质量的系统。
4. 模式被认为时历经验证的OO设计经验。
5. 模式不是代码，而是针对设计问题的通用解决方案。你可把它们应用到特定的应用中。
6. 模式不是被发明，而是被发现。
7. 大多数的模式和原则，都着眼于软件变化的主题。
8. 大多数的模式都允许系统局部改变独立于其他部分。
9. 我们常把系统中会变化的部分抽出来封装。
10. 模式让开发人员之间有共享的语言，能最大化沟通价值。