Head First 设计模式--Strategy

本系列是我自己学习“Head First Design Pattern”一书的读书笔记和心得。将按照每次一个Chapter的顺序进行记录。欢迎大家分享你的学习心得。

 

Chapter 1 --设计模式入门

 

1.  对代码的局部修改，影响的层面不只是局部（会影响到子类的行为，出现“会飞的橡皮鸭”的情况）。所以，当涉及“维护”时，为了“复用”（reuse）目的而使用继承，结局并不完美。

2.  因为Java接口不具有实现代码，所有继承接口无法达到代码的复用。这意味着：无论何时你需要修改某个行为，你必须得往下追踪并在每一个定义此行为的类中修改它，一不小心，可能会造成新的错误！

 

3. 设计模式致力于提高可维护性和可扩展性上的复用程度，是系统更有弹性。

 

 

本章使用SimuDuck的例子来说明以下来三个设计原则：

 

(1)  找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
也就是说：把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分。

 

(2)  针对接口编程，而不是针对实现编程。

”针对接口编程“，关键就在多态。利用多态，程序可以针对超类型编程，执行时会根据实际状况执行到真正的行为，不会被绑死在超类型的行为上。

 

所谓针对接口编程和针对实现编程的区别如下：

 

a)  针对实现编程

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

 

b)  针对接口编程

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

 

更值得注意的是，子类实例化的动作不再需要在代码中硬编码，例如new Dog()，而是“在运行时才指定具体实现的对象”。

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

 

(3) 多用组合，少用继承 

使用组合建立系统具有很大的弹性，不仅可将算法族封装成类，更可以“在运行时动态地改变行为”，只要组合的行为对象符合正确的接口标准即可。

 

 

策略模式：

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

 

 

本章小结：

 

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