Head First Design Patterns HeadFirst 设计模式

OO原则是我们的目标，而设计模式是我们的做法。

---

策略模式 (Strategy)

在软件开发上，一直不变的真理是“change”。不管软件设计的多好，一段时间之后，总是要成长与改变，否则软件就会“死亡”。

• 策略模式(Strategy)：定义算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
• 代码关键点：某个行为设计为接口，行为的具体实现由具体类来完成。
• 书中例子：鸭子与鸭子的行为，以组合的方式组织，鸭子的行为以接口表示，接口可能有多个具体的实现形式。具体的鸭子类可以动态的设置行为的具体方式。
• 封装变化：找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。把会变化的部分取出并“封装”起来，好让其他部分不会受到影响。
• 针对“接口”编程，而不是针对实现编程。
• 多用组合，少用继承。
• 建立可维护的OO系统，要诀就在于随时想到系统以后可能需要的变化以及应付变化的原则。
• 良好的OO设计必须具备可复用、可扩充、可维护三个特性。
• 大多数的模式和原则，都着眼于软件变化的主题。
• 大多数的模式都允许系统局部改变独立于其他部分。我们常把系统中会变化的部分抽出来封装。

---

观察者模式 (Observer)

设计原则：为了交互对象之间的松耦合而努力

• 观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
• 被观察者是真正拥有数据，观察者是其依赖者，在数据变化时更新，这样比起让许多对象控制同一份数据，可以得到更干净的OO设计。
• 代码关键点：在被观察者类/数据类中加入了观察者类的注册list成员列表，在列表中的成员为注册成员，接收数据通知。“拉”数据的模式还要求观察者类中包含一个被观察者成员变量。
• 推Push与拉Pull：观察者获取数据的方式是通过notifyObserver(Object)进行传输，或观察者调用被观察者的getData()获取数据。一般认为“推的方式更正确” [观点：例如数据的变动很频繁，让观察者拉数据不一定能够满足要求，各个观察者所获取的数据也可能是不一致的]。
• 消息传递链条(方法调用步骤)
  • 数据源数据变化
  • 调用自身的setData(...);
  • 调用数据改变方法setChanged();//便于控制消息通知
  • 调用notifyObservers(Obj);//推与拉的关键仅仅在于Object是否传输
  • for each O in Observers , .o.update()
• 一对多，松耦合
• 若调用java.util.Observerable，不要依赖于观察者被通知的次序。
• 观察者和可观察者之间用松耦合方式结合，可观察者不知道观察者的细节，只知道观察者实现了观察者接口update()。
• 有多个观察者时，不可以依赖特定的通知次序。
• Java有多种观察者模式的实现，包括了通用的java.util.Observerable.
• 此模式被应用在许多地方，例如许多的GUI框架/Swing，JavaBeans、RMI。

//被观察者
public class WeatherData implements Subject {
    private List observers;//关键点1
    private Object data;
    private boolean changed;

    public WeatherData() {
        observers = new ArrayList();
    }

    public void registerObserver(Observer o) {...}//注册
    public void removeObserver(Observer o) {...}//移除s

    public void setData(Object data) {//更新数据
        this.data = data;
        dataChanged();
    }

    public void dataChanged() {
        setChanged();
        if(是否达到推送更新数据条件) {
            notifyObservers();
        }
    }
    public void setChanged() {//数据已改变
        changed = true;
    }

    /**
    * arg即为所要传送的数据，如果为拉模式，arg=null, 数据在所传输的this被观察者对象中
    */
    public void notifyObservers(Object arg) {
        if(changed) {
            for(Observer observer : observers) {
                observer.update(this, arg);
            }
            changed = false;
        }
    }
}

public class OneObserver implements Observer {
    private Subject weatherData;//关键点2
    private Object data;

    public OneObserver(Subject s) {//构造器，注册
        this.weatherData = s;
        weatherData.registerObserver(this);
    }

    public void update(Object observerable, Object arg) {//更新数据接口
        this.data = arg;
    }
}

---

装饰者模式 (Decorator)

给爱用继承的人一个全新的设计眼界

• 开放-关闭原则：类应该对扩展开放，对修改关闭。
• 装饰者模式：动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
  • 装饰者和被装饰对象有相同的超类型。在任何需要原始对象的场合，可以用装饰过的对象替代它。
  • 可以用一个或多个装饰者包装一个对象。
  • 用装饰来包裹一个对象，动态的扩展功能
  • 装饰者可以在被委托装饰者的行为之前与/或之后，加上自己的行为，已达到特定的目的。
  • 对象可以在任何时候被装饰，所以可以在运行时动态地、不限量地用你喜欢的装饰者来装饰对象。
• Java库中的装饰者模式：
  • Java I/O
  • Reader/Writer
    
    
• 装饰者模式缺点：常常造成设计中有大量的小类，数量实在太多，可能造成使用此API程序员的困扰。
• 要点：
  • 继承属于扩展形式之一,但不见得是达到弹性设计的最佳方式。
  • 在我们的设计中，

/**
 * 	被装饰者基类
 */
public abstract class BaseBeverage {
	String description = "Unknown Beverage";

	public String getDescription() {
		return description;
	}

	public abstract double cost();
}

/**
 * 	装饰者基类
 */
public abstract class BaseCondimentDecorator extends BaseBeverage {
	public abstract String getDescription();
}

/**
 * 	被装饰者实体类
 */
public class Espresso extends BaseBeverage {
	public Espresso() {
		description = "Espresso";
	}

	@Override
	public double cost() {
		return 1.99;
	}
}

/**
 *	装饰者实体类
 */
public class Mocha extends BaseCondimentDecorator {
	BaseBeverage beverage;

	public Mocha(BaseBeverage beverage) {
		this.beverage = beverage;
	}
	@Override
	public String getDescription() {
		return beverage.getDescription() + ", Mocha";
	}

	@Override
	public double cost() {
		return 0.2 + beverage.cost();
	}
}

/**
*  装饰者使用方法
*/
public class StarBuzzCoffee {
	public static void main(String[] args) {
		BaseBeverage beverage = new Espresso();
		System.out.println(beverage.getDescription() + "￥" + beverage.cost());

		BaseBeverage beverage2 = new Espresso();
		beverage2 = new Mocha(beverage2);
		beverage2 = new Mocha(beverage2);
		System.out.println(beverage2.getDescription() + "￥" + beverage2.cost());
	}
}

工厂模式 (Factory)

除了new操作符之外，还有更多制造对象的方法。实例化这个活动不应该总是公开地进行，也会认识到初始化经常造成“耦合”问题。

理解关键点：工厂方法是将对象实例化延迟在具体子类中实现，返回不同的产品；抽象工厂模式（公共接口会抽象类）是为了创建产品家族，实现不同的工厂，制造出不同的产品、不同的区域、不同的操作系统、不同的外观及操作。

• 工厂方法模式：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。
• 依赖倒置原则：要依赖抽象，不要依赖具体类。
• 几个避免你违反 依赖倒置 的指导方针
  
  - 变量不可以持有具体类的引用。（如果使用new，就会持有具体类的引用。你可以改用工厂来避开这样的做法。）
  
  - 不要让类派生自具体类。（如果派生自具体类，你就会依赖具体类。请派生自一个抽象——接口或抽象类）
  
  - 不要覆盖基类中已实现的方法。（如果覆盖基类已实现的方法，那么你的基类就不是一个真正适合被继承的抽象。基类中已实现的方法，应该由所有的子类共享）
• 不能让高层组件依赖低层组件，而且，不管高层或低层组件，“两者”都应该依赖于抽象。
• 工厂方法用来处理对象的创建，并将这样的行为封装在子类中。这样，客户程序中关于超类超类的代码就和子类对象创建代码解耦了。
• 工厂方法模式通过让子类决定该创建的对象是什么，来达到将对象创建的过程封装的目的。

/**
* 工厂方法模式
*/
public abstract class ProductFactory {
    //获取对象
    public Product getProduct(String type) {
        Product product;
        product = createProduct(type);

        //call product same method
        product.prepare();
        product.bake();
        product.cut();
        product.box();

        return product;
    }

    //工厂方法
    public abstract Product createProduct(String type);
}

public abstract class Product {
    String  name;
    void prepare() { }
    void bake() { }
    void cut() { }
    void box() { }
}

abstract Product factoryMethod(String);
/**
*	1. 工厂方法是抽象的，所以依赖子类来处理对象的创建；
* 2. 工厂方法必须返回一个产品。超类中定义的方法，通常使用到工厂方法的返回值。
*	3. 工厂方法将客户和实际创建具体产品的代码分隔开来。
*	4. 工厂方法可能需要参数来指定所要的产品。
*/

• 抽象工厂模式：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
• 抽象工厂使用对象组合：对象的创建被实现在工厂接口所暴露出来的方法中。

/**
* 抽象产品类
*/
public abstract class Product {
    String name;
    String source;
    abstract void prepare();
}

/**
* 抽象原料工厂
*/
public abstract class ProductIngredientFactory {
    void createSource() { }
}

/**
* 具体产品类
*/
public class RealProduct extends  Product {
    //生产产品所需的某种原料的工厂
    ProductIngredientFactory ingredientFactory;

    public RealProduct(ProductIngredientFactory ingredientFactory) {
        this.ingredientFactory = ingredientFactory;
    }

    @Override
    void prepare() {
        source = ingredientFactory.createSource();
    }
}

单件模式 (Singleton)

用来创建独立无二的，只能有一个实例的对象的入场券

• 全局变量的缺点：必须在程序一开始就创建好对象，万一这个对象非常耗费资源，而程序在这次的执行过程中又一直没用到它，不就形成浪费了吗.(某些JVM在用到的时候才创建对象).
• 例如线程池、缓存、对话框、处理偏好设置和注册表的对象、日志对象，充当打印机、显卡等设备的驱动程序的对象，这些对象只能有一个。
• 单件模式常被用来管理共享资源，例如数据库连接或线程池。
• 单件模式 确保一个类只有一个实例，并提供一个全局访问点。
• 在java中实现单件模式需要私有构造器、一个静态方法和一个静态变量。
• 确定在性能和资源上的限制，然后小心地选择适当的方案来实现单件，以解决多线程问题。
• 如果你使用多个 类加载器 ，可能导致单件失效而产生多个实例。

/**
* 未考虑并发的单件模式
*/
public class Singleton {
    private static Singleton uniqueInstance;
    private Singleton() {}
    public static Singleton getInstance() {
        if (uniqueInstance == null) {
            uniqueInstance = new Singleton();
        }
        return  uniqueInstance;
    }
}

/**
* 考虑并发的单件模式
* 较好方式：双重检查加锁
* 注意：要使用volatile-synchronized(不适用于java1.4或更早之前的版本)
*
* 1. 采用“急切”创建实例，即在声明处就创建对象。如果对象在创建和运行时很繁重，不推荐此种方法。
* 2. 单纯使用synchronized设置整个方法为同步方法。性能较差
*/
public class SupportParrallSingleton {
    private volatile static SupportParrallSingleton uniqueInstance;
    public static SupportParrallSingleton getInstance(){
        if (uniqueInstance == null) {
            synchronized (SupportParrallSingleton.class) {
                if (uniqueInstance == null) {
                    uniqueInstance = new SupportParrallSingleton();
                }
            }
        }
        return uniqueInstance;
    }
}

命令模式 (Command)

把方法调用封装起来

• 命令模式 将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。
• 命令模式将发出请求的对象和执行请求的对象解耦。
• 在被解耦的两者之间是通过命令对象进行沟通的。命令对象封装了接受者和一个或一组动作。
• 调用者通过调用命令对象的execute()发出请求，这会使得接受者的动作被调用。
• 调用者可以接受命令当做参数，甚至在运行时动态地进行。
• 命令可以支持撤销，做法是实现一个undo()方法来回到execute()被执行前的状态。
• 宏命令是命令的一个简单延伸，允许调用多个命令。宏方法可以支持撤销。
• 实际操作中，很常见使用“聪明”命令对象，也就是直接实现了请求，而不是将工作委托给接收者。
• 命令也可以用来实现日志和事务系统。
• 命令模式的更多用途：
  • 队列请求 例如：日程安排、线程池、工作队列等。（想象有一个工作队列：你在一端添加命令，然后另一端则是线程。线程进行下面的动作：从队列中取出一个命令，然后调用它的execute()方法，等待这个调用完成，然后将此命令对象丢弃，再取出下一个命令……）
  • 日志请求 例如：系统检查点后的一系列操作；事务处理（Transaction）

/**
* 思考餐厅的下单过程：
*/
/**
*	接口：命令对象
* 例如，顾客交给服务员的订单，遥控器按钮所传输的对象
* 注意：命令对象是个接口，将请求的对象和执行请求的对象进行沟通（关联在实现中）
*/
public interface Command {
	public void execute();
}

/**
*	 注意：将请求的对象和执行请求的对象进行沟通（关联在实现中）
*/
public class LightOnCommand implements Command {
	Light light;//执行请求的对象

	public LightOnCommand(Light light) {
		this.light = light;
	}

	@Override
	public void execute() {//执行请求的对象调用的方法
		light.on();
	}
}

/**
 * 	执行请求的对象（类似：餐厅厨师）
 */
public class Light {
	public void on() {
		System.out.println("light on");
	}
}

/**
 * 	动作发起者：类似餐厅顾客
 */
public class SimpleRemoteControl {
	Command slot;

	public void setCommand(Command command) {//顾客下单
		this.slot = command;
	}

	public void buttonWasPressed() {//提交订单
		slot.execute();
	}
}

/**
* 执行流程
*/
public class CommandPatternTest {
	public static void main(String[] args) {
		SimpleRemoteControl remote = new SimpleRemoteControl();
		Light light = new Light();
		LightOnCommand lightOnCommand = new LightOnCommand(light);
		remote.setCommand(lightOnCommand);
		remote.buttonWasPressed();
	}
}

//TODO MORE

总结

• 封装变化
• 多用组合，少用继承
• 针对接口编程，不针对实现编程
• 为交互对象之间的松耦合而努力
• 类应该对扩展开放，对修改关闭
• 依赖抽象，不要依赖具体类