Head First 学习笔记.docxVIP

HeadFirst 学习笔记1. 书中列举的设计原则1、封装变化。找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。2、针对接口编程，而不是针对实现编程。举例说明：假设有一个抽象类Animal，有两个具体的实现（Dog与Cat）继承Animal。“针对实现编程”的做法：Dog d = new Dog();d.bark();“针对接口编程”的做法：Animal animal = new Dog();animal.makeSound();或者：Animal animal = getAnimal();animal.makeSound();3、多用组合，少用继承。原因：?a、继承会使类无限膨大，可能会使类变得臃肿。?b、子类可能会继承父类中那些无用甚至有害的方法。?c、组合比继承更灵活，可以实现在执行中动态改变对象的功能。4、为了交互对象之间的松耦合设计而努力。5、类应该对修改关闭，对扩展开放。6、要依赖抽象，不要依赖具体类。解释：不要让“高层组件”依赖“低层组件”，而且，不管“高层组件”还是“低层组件”，两者都应该依赖于抽象。避免违反该原则的几个方针：变量不可以持有具体类的引用。如果使用new，就会持有具体类的引用，可以使用工厂来避开这种引用。不要让类派生自具体类。如果派生自具体类，就会依赖具体类，可以派生自抽象或接口。不要覆盖基类中已实现的方法。如果覆盖基类中已实现的方法，那么基类就不是一个真正适合被继承的类。基类中已实现的方法应该被所有子类所共享。7、最少知识原则。解释：当你设计一个系统时，不管是任何对象，你都要注意与它交互的类有哪些，并注意它和这些类是如何交互的，尽量避免过多的类耦合在一起，带来维护成本的上升。这个原则推荐的一些方针：就任何对象而言，在该对象的方法内，我们只应该调用一下范围的方法1）、该对象本身2）、被当作方法的参数而传递进来的对象3）、此方法所创建或实例化的任何对象4）、对象的任何组件。2. /wxj1020/archive/2008/03/21/1115540.html策略模式先对策略模式有一个总体认识。意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。结构：下面通过鸭子模拟器的设计来具体介绍。公司需要设计一套鸭子模拟器系统，该系统的第一次需求为：鸭子能够戏水；鸭子能够呱呱叫。根据该需求系统设计如下：这个设计主要用了父类鸭子和子类绿头鸭、红头鸭，这样设计的目的是为了达到代码的复用。过了一段时间，公司希望该系统能够满足新的需求：有些鸭子会飞。因此该系统需要进行修改，修改后的系统可能如下：该系统在父类中加了“fly（）”方法（在父类中加该方法是为了实现代码的复用）。这里就出现了两个问题：（1）、所有的鸭子都会飞了。（2）、所有鸭子的叫声都一样，都是“呱呱”叫。注：这两个问题可以通过子类中方法覆盖来解除，但这样处理不是很好。鸭子的类别越多，这种处理的缺点就越明显。其实这个系统的变化点是鸭子的叫声和鸭子的飞行能力，因此我们很容易想到把鸭子的叫声和鸭子的飞行能力做成接口，把这些变化的地方封装起来，这样上面的两个问题都可以解决，所以系统可能被修改为下面的样子：MallardDuck和RedheadDuck既会飞又会叫，RubberDuck只会叫不会飞，DecoyDuck不会飞也不会叫。应该说这个系统没有问题了，从表面看这种设计完全符合需求，而且完全符合面向对象的理念，但是当鸭子的类别很多时，你会发现这种设计缺乏代码的复用，这两个独立出来的接口似乎没有任何意义，根本无法减轻工作量，还不如原来的设计呢。所以你可能会想到问题的关键是接口中的方法没有实现，那我们该怎么办呢？我们的做法是把接口做成类，运用组合的方法来实现需求。考虑到“针对接口编程，而不是针对实现编程”的设计原则，我们的系统可能就会设计成如下的结构，这个结构就是应用了“策略”模式。/wxj1020/archive/2008/03/24/1119703.html3. 观察者模式意图：定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。结构：例子：下面以模拟气象站系统来加以说明。需求分析：该系统的需求如下：1、气象站能够追踪目前的天气状况，包括温度、湿度、气压、2、气象站能够提供三种布告板，分别显示目前天气状况、气象统计和简单的预报。3、布告板上的数据必须实时更新。4、气象站必须提供一组API，供其他开发人员开发其他的布告板。设计部分：基于以上需求，该系统可以设计成3部分：气象站（获取实际气象数据的物理装置）、WeatherData对象（追踪来自气象站的数据，并更新布告板）和布告板（显示目前的天气状况给用户看）。效果图如下：