HeadFirst 学习笔记
时间：2010-04-19 来源：yf956613
策略（Strategy）模式：定义一组算法族，分别封装起来，让各个算法之间可以相互替换。此模式让算法的变化独立于使用算法的客户。
观察者模式：定义了对象之间的一对多依赖关系，当一个对象（主题对象）的状态改变时，它的所有依赖者（观察者对象）都会收到通知并自动更新。
装饰者模式：动态地将责任加到对象身上。如果要扩展功能，装饰者模式提供了比继承更有弹性的替代方案。
*用静态方法定义的工厂被成为静态工厂，这样就不用使用创建对象的方法来实例化对象，使用方便。但是这样做的缺点是无法通过继承来改变创建方法的行为。
*简单工厂不是一种设计模式，但是它比较常用。
*工厂方法用来处理对象的创建，并将这样的行为封装在子类中。这样，客户程序中关于超类的代码就和子类对象的创建代码解耦（Decouple）了。
工厂方法的定义：abstract Product factoryMethod(String type);
工厂（Factory Method Pattern）方法模式：定义了一个创建对象的接口，但是由子类来决定要实例化的类是哪一个。它让类把实例化推迟到了子类。
抽象工厂模式：提供一个接口，用于创建相关或者依赖对象的家族，而不需要明确指定具体类。
单件（Singleton）模式：确保一个类只有一个实例，并提供一个全局访问点。
命令（Command）模式：将“请求”封装成对象，以便使用请求、队列或日志来参数化其它对象。命令模式也支持可撤销的操作。
适配器模式：将一个类的接口，转换成客户希望的另一个接口。适配器让原本接口不兼容的类合作无间。
外观模式：提供了一个统一的接口，用来访问子系统中的一群接口。外观模式定义了一个高层接口，让子系统更容易使用。
迭代器模式：提供一种顺序访问集合对象中各个元素的方法，而又不暴露其内部的表示（也就是数据结构）。
组合模式：将对象组合成树状结构来表现“整体/部分”的层级结构，让客户以一致的方式来处理个别对象以及对象组合。
模板方法模式：在一个方法中定义了一个算法的骨架，而将一些步骤延迟到子类中。模板方法可以让子类在不改变算法结构的情况下，重新定义算法中的某些步骤。
状态（State）模式：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
代理模式：为另一个对象提供替身或占位符以控制对这个对象的访问。
*复合模式在一个解决方案中结合两个或多个模式，以解决一般或重复发生的问题。
*视图（View）：用来呈现模型。视图通常直接从模型中取得它需要显示的数据和状态。
*控制器（Controller）：取得用户的输入并解读其对模型的含义。
*模型（Model）：模型持有所有的数据、状态和程序逻辑。模型没有注意到视图和控制器，虽然它提供了操纵和检索状态的接口，并发送状态改变通知给观察者。
模式：是在某种情境下（Context），针对某个问题的某种解决方案。
反模式：告诉你如何采用一个不好的解决方案解决一个问题。
2、面向对象设计原则
封装变化--把软件中那些在将来可能产生变化的地方独立出来，与其他部分分割以减少变化时对它们的影响。这样的设计可以使系统变得有弹性，更好地应对变化。
针对接口编程，而不针对实现编程。依据该原则，声明一个变量时要把它声明为超类型（接口或抽象类），而不是实现类。
多用组合，少用继承。使用组合的方式可以实现代码的分割，使代码有更大的弹性，更好地提高了复用性。
努力在交互对象之间实现松耦合，使它们之间的互相依赖降到最低，从而提高可复用性。
类应该对扩展开放，对修改关闭。这就是我们常说的开放-关闭原则。
要依赖抽象，不要依赖具体类。这个原则又被称为“依赖倒置原则（Dependency Inversion Principle）”。
*遵循依赖倒置原则的三个指导方针：
（1）变量不可以持有具体类的引用。这可以通过使用工厂避开。
（2）不要让类派生自具体类。否则就会依赖具体类，违反了“针对接口编程，而不是针对现实编程”的软件设计原则。
（3）不要覆盖基类中已实现的方法。出现这样的情况就说明基类设计的有问题。
要减少对象之间的交互，只留下几个“密友”。这个原则被称为“最少知识（Least Knowledge）原则”，它告诉我们只和自己的密友谈话。
*通过只调用以下几种范围内的方法可以做到尽量遵循“最少知识原则”：
（1）该对象本身
（2）被当做方法的参数而传递进来的对象
（3）此方法所创建或实例化的任何对象
（4）对象的任何组件，比如类或对象本身的变量，或常量
*最少知识原则的不同名称：(Principal of) Least Knowledge，(The) Law of Demeter，迪米特法则，得墨忒耳法则
一个类应该只有一个引起变化的原因。
别调用（打电话给）我们，我们会调用（打电话给）你。这个原则被成为好莱坞原则。
3、模式使用事项
*装饰者模式的几个缺点：
（1）有时在设计中加入大量的小类，变得不容易理解。
（2）有的客户端代码依赖于特定的类型（这是个比较糟糕的习惯，违反了“针对接口编程，而不是针对实现编程”的设计原则），当服务器端引入装饰者模式时，客户端就会出现状况。
（3）装饰者模式使得实例化组件的复杂度提升。
PS：工厂（Factory）模式和生成器（Builder）模式对于装饰者（Decorator）模式的这些缺点会有所帮助。
*空对象（null object）可以用于返回无意义的对象时，它可以承担处理null的责任。有时候空对象也被视为一种设计模式。
*宏命令（Macro Command）是一个命令队列，它包含了一组实现了同一个命令接口的类。
*在调用者中用一个堆栈记录连续执行的命令，这样就可以实现每按一次按钮就执行一次撤销操作的连续撤销功能。
*适配器（Adapter）类看起来很像命令（Command）模式中命令接口的实现类，只不过它不被作为参数传递。
*类适配器是基于多重继承实现的，因为Java不支持多重继承，因此无法做到。
装饰者（Decorator）模式与适配器（Adapter）模式的区别
（1）装饰者模式与“责任”相关，当涉及到装饰者时，就表示有一些新的行为或责任要加到设计中。
（2）适配器允许客户使用新的库和子集合，无须改变“任何”已存在的代码，由适配器负责转换即可。
（3）装饰者不会改变接口，而适配器会改变接口。
（4）装饰者的工作是扩展被包装对象的行为或责任，并不是“简单传递”就算了。
（5）装饰者（Decorator）模式与适配器（Adapter）模式的最大不同在于使用它们的意图（或目的）。
*使用最少知识原则的缺点是：更多的“包装类”被创造出来，以处理和其它组件的沟通。这可能导致复杂度和开发时间的增加，并减低运行时的性能。
*组合（Composite）模式牺牲了单一责任设计原则，换取了透明性（Transprency）。
*空迭代器（Iterator）是空对象（null object）“设计模式”的又一个例子，之前的例子是“空命令（NullCommand）”。
*为了保证模板方法定义的算法步骤不被改变，模板方法被声明为final的。
*钩子（hook）就是回调函数，它可以作为条件影响模板方法类中算法的流程。
代理模式有很多变种，几乎都与控制访问有关，它控制访问的几种方式：
一、远程代理控制远程对象的访问。
二、虚拟代理控制创建开销大的资源的访问。
三、保护代理基于权限控制对资源的访问。
*不把控制器的代码（解读视图的输入并操纵模型）放到模型中的原因有两个：
一、会让模型的代码更复杂。模型将具有两个责任，不但要管理用户界面，还要处理如何控制模型的逻辑。
二、会造成模型和视图之间的紧耦合，降低了可复用性。通过模型和视图之间的解耦，使设计更有弹性和容易扩展，能容纳改变。
关于鸭子：
class Duck { public: virtual ~Duck() = 0 {
}
public: virtual void fly() const = 0;
public: virtual void quack() const = 0;
}; class MallardDuck : public Duck { public: void fly() const {
std::cout << "I'm flying" << std::endl;
}
public: void quack() const {
std::cout << "Quack" << std::endl;
}
};
class TurkeyAdapter : public Duck { private: const Turkey* _turkey; private: TurkeyAdapter( const TurkeyAdapter& ); // Disable copy constructor
private: void operator=( const TurkeyAdapter& ); // Disable assignment operator public: explicit TurkeyAdapter( const Turkey* turkey ) :
_turkey( turkey ) { assert( turkey );
}
public: void fly() const { assert( _turkey );
for( int i = 0; i < 5; i++ ) {
_turkey->fly();
}
}
public: void quack() const { assert( _turkey );
_turkey->gobble();
}
};
观察者模式：定义了对象之间的一对多依赖关系，当一个对象（主题对象）的状态改变时，它的所有依赖者（观察者对象）都会收到通知并自动更新。
装饰者模式：动态地将责任加到对象身上。如果要扩展功能，装饰者模式提供了比继承更有弹性的替代方案。
*用静态方法定义的工厂被成为静态工厂，这样就不用使用创建对象的方法来实例化对象，使用方便。但是这样做的缺点是无法通过继承来改变创建方法的行为。
*简单工厂不是一种设计模式，但是它比较常用。
*工厂方法用来处理对象的创建，并将这样的行为封装在子类中。这样，客户程序中关于超类的代码就和子类对象的创建代码解耦（Decouple）了。
工厂方法的定义：abstract Product factoryMethod(String type);
工厂（Factory Method Pattern）方法模式：定义了一个创建对象的接口，但是由子类来决定要实例化的类是哪一个。它让类把实例化推迟到了子类。
抽象工厂模式：提供一个接口，用于创建相关或者依赖对象的家族，而不需要明确指定具体类。
单件（Singleton）模式：确保一个类只有一个实例，并提供一个全局访问点。
命令（Command）模式：将“请求”封装成对象，以便使用请求、队列或日志来参数化其它对象。命令模式也支持可撤销的操作。
适配器模式：将一个类的接口，转换成客户希望的另一个接口。适配器让原本接口不兼容的类合作无间。
外观模式：提供了一个统一的接口，用来访问子系统中的一群接口。外观模式定义了一个高层接口，让子系统更容易使用。
迭代器模式：提供一种顺序访问集合对象中各个元素的方法，而又不暴露其内部的表示（也就是数据结构）。
组合模式：将对象组合成树状结构来表现“整体/部分”的层级结构，让客户以一致的方式来处理个别对象以及对象组合。
模板方法模式：在一个方法中定义了一个算法的骨架，而将一些步骤延迟到子类中。模板方法可以让子类在不改变算法结构的情况下，重新定义算法中的某些步骤。
状态（State）模式：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
代理模式：为另一个对象提供替身或占位符以控制对这个对象的访问。
*复合模式在一个解决方案中结合两个或多个模式，以解决一般或重复发生的问题。
*视图（View）：用来呈现模型。视图通常直接从模型中取得它需要显示的数据和状态。
*控制器（Controller）：取得用户的输入并解读其对模型的含义。
*模型（Model）：模型持有所有的数据、状态和程序逻辑。模型没有注意到视图和控制器，虽然它提供了操纵和检索状态的接口，并发送状态改变通知给观察者。
模式：是在某种情境下（Context），针对某个问题的某种解决方案。
反模式：告诉你如何采用一个不好的解决方案解决一个问题。
2、面向对象设计原则
封装变化--把软件中那些在将来可能产生变化的地方独立出来，与其他部分分割以减少变化时对它们的影响。这样的设计可以使系统变得有弹性，更好地应对变化。
针对接口编程，而不针对实现编程。依据该原则，声明一个变量时要把它声明为超类型（接口或抽象类），而不是实现类。
多用组合，少用继承。使用组合的方式可以实现代码的分割，使代码有更大的弹性，更好地提高了复用性。
努力在交互对象之间实现松耦合，使它们之间的互相依赖降到最低，从而提高可复用性。
类应该对扩展开放，对修改关闭。这就是我们常说的开放-关闭原则。
要依赖抽象，不要依赖具体类。这个原则又被称为“依赖倒置原则（Dependency Inversion Principle）”。
*遵循依赖倒置原则的三个指导方针：
（1）变量不可以持有具体类的引用。这可以通过使用工厂避开。
（2）不要让类派生自具体类。否则就会依赖具体类，违反了“针对接口编程，而不是针对现实编程”的软件设计原则。
（3）不要覆盖基类中已实现的方法。出现这样的情况就说明基类设计的有问题。
要减少对象之间的交互，只留下几个“密友”。这个原则被称为“最少知识（Least Knowledge）原则”，它告诉我们只和自己的密友谈话。
*通过只调用以下几种范围内的方法可以做到尽量遵循“最少知识原则”：
（1）该对象本身
（2）被当做方法的参数而传递进来的对象
（3）此方法所创建或实例化的任何对象
（4）对象的任何组件，比如类或对象本身的变量，或常量
*最少知识原则的不同名称：(Principal of) Least Knowledge，(The) Law of Demeter，迪米特法则，得墨忒耳法则
一个类应该只有一个引起变化的原因。
别调用（打电话给）我们，我们会调用（打电话给）你。这个原则被成为好莱坞原则。
3、模式使用事项
*装饰者模式的几个缺点：
（1）有时在设计中加入大量的小类，变得不容易理解。
（2）有的客户端代码依赖于特定的类型（这是个比较糟糕的习惯，违反了“针对接口编程，而不是针对实现编程”的设计原则），当服务器端引入装饰者模式时，客户端就会出现状况。
（3）装饰者模式使得实例化组件的复杂度提升。
PS：工厂（Factory）模式和生成器（Builder）模式对于装饰者（Decorator）模式的这些缺点会有所帮助。
*空对象（null object）可以用于返回无意义的对象时，它可以承担处理null的责任。有时候空对象也被视为一种设计模式。
*宏命令（Macro Command）是一个命令队列，它包含了一组实现了同一个命令接口的类。
*在调用者中用一个堆栈记录连续执行的命令，这样就可以实现每按一次按钮就执行一次撤销操作的连续撤销功能。
*适配器（Adapter）类看起来很像命令（Command）模式中命令接口的实现类，只不过它不被作为参数传递。
*类适配器是基于多重继承实现的，因为Java不支持多重继承，因此无法做到。
装饰者（Decorator）模式与适配器（Adapter）模式的区别
（1）装饰者模式与“责任”相关，当涉及到装饰者时，就表示有一些新的行为或责任要加到设计中。
（2）适配器允许客户使用新的库和子集合，无须改变“任何”已存在的代码，由适配器负责转换即可。
（3）装饰者不会改变接口，而适配器会改变接口。
（4）装饰者的工作是扩展被包装对象的行为或责任，并不是“简单传递”就算了。
（5）装饰者（Decorator）模式与适配器（Adapter）模式的最大不同在于使用它们的意图（或目的）。
*使用最少知识原则的缺点是：更多的“包装类”被创造出来，以处理和其它组件的沟通。这可能导致复杂度和开发时间的增加，并减低运行时的性能。
*组合（Composite）模式牺牲了单一责任设计原则，换取了透明性（Transprency）。
*空迭代器（Iterator）是空对象（null object）“设计模式”的又一个例子，之前的例子是“空命令（NullCommand）”。
*为了保证模板方法定义的算法步骤不被改变，模板方法被声明为final的。
*钩子（hook）就是回调函数，它可以作为条件影响模板方法类中算法的流程。
代理模式有很多变种，几乎都与控制访问有关，它控制访问的几种方式：
一、远程代理控制远程对象的访问。
二、虚拟代理控制创建开销大的资源的访问。
三、保护代理基于权限控制对资源的访问。
*不把控制器的代码（解读视图的输入并操纵模型）放到模型中的原因有两个：
一、会让模型的代码更复杂。模型将具有两个责任，不但要管理用户界面，还要处理如何控制模型的逻辑。
二、会造成模型和视图之间的紧耦合，降低了可复用性。通过模型和视图之间的解耦，使设计更有弹性和容易扩展，能容纳改变。
关于鸭子：
class Duck { public: virtual ~Duck() = 0 {
}
public: virtual void fly() const = 0;
public: virtual void quack() const = 0;
}; class MallardDuck : public Duck { public: void fly() const {
std::cout << "I'm flying" << std::endl;
}
public: void quack() const {
std::cout << "Quack" << std::endl;
}
};
class TurkeyAdapter : public Duck { private: const Turkey* _turkey; private: TurkeyAdapter( const TurkeyAdapter& ); // Disable copy constructor
private: void operator=( const TurkeyAdapter& ); // Disable assignment operator public: explicit TurkeyAdapter( const Turkey* turkey ) :
_turkey( turkey ) { assert( turkey );
}
public: void fly() const { assert( _turkey );
for( int i = 0; i < 5; i++ ) {
_turkey->fly();
}
}
public: void quack() const { assert( _turkey );
_turkey->gobble();
}
};
相关阅读 更多 +
