首页 > 代码库 > 设计模式总结(2)

设计模式总结(2)

设计模式总结(2)
 
======================================================
decorator pattern
 
 
装饰者和被装饰者有相同的 超类型;
可以用一个或多个 装饰者来 包装 一个对象;
既然装饰者和被装饰者对象有相同的超类型,所以在
任何需要原始对象(被包装的)的场合,可以用装饰过的
对象代替;
装饰者可以在所委托被装饰者的行为之前或之后,加上自己的行为,
以达到特定的目的;
对象可以在任何时候被装饰,所以可以在运行时动态的、不限量的用
不同的装饰者来装饰对象。
 
 
 
decorator pattern:
动态地将责任附加到对象上,若要扩展功能,
装饰者提供了比继承更有弹性的替代方案。
 
 
oo principle
对扩展开放,对修改关闭。
 
 
继承属于扩展形式之一,但不见得是达到弹性设计的最佳方式。
应该允许行为可以被扩展,而无需修改现有的代码。
组合和委托可用于在运行时动态地加上新的行为。
 
 
一组装饰者类,一组组件类(被装饰被包装被多层包装)。
具有相同的基类。
 
 
 
 
 
======================================================
factory pattern
 
 
工厂方法模式与简单工厂模式再结构上的不同不是很明显。
工厂方法类的核心是一个抽象工厂类,而简单工厂模式把核心放在一个具体类上。
工厂方法模式之所以有一个别名叫多态性工厂模式是因为具体工厂类都有共同的接口,
或者有共同的抽象父类。
 
当系统扩展需要添加新的产品对象时,仅仅需要添加一个具体对象
以及一个具体工厂对象,原有工厂对象不需要进行任何修改,也不需要修改客户端,
很好的符合了"开放-封闭"原则。而简单工厂模式在添加新产品
对象后不得不修改工厂方法,扩展性不好。
工厂方法模式退化后可以演变成简单工厂模式。
 
 
decouple 解耦
 
 
一个对象负责所有的具体类的实例化;
一群子类负责相应的具体类的实例化。
 
 
工厂方法用来处理对象的创建,并将这样的行为
封装到子类中;这样,客户程序中关于超类的代码就和
子类对象创建代码解耦了。
 
 
 
工厂方法模式定义了一个创建对象的接口,
但由子类决定要实例化的类是哪一个。
工厂方法让类把实例化推迟到子类。
 
 
Dependency Inversion Principle 依赖倒置原则
--要依赖抽象,不要依赖具体类。
 
 
 
 
1.变量不可以持有具体类的引用:如果使用new,
就会持有具体类的引用;
2.不要让类派生自具体的类:如果派生自具体类,
就会依赖具体类,要派生自一个抽象;
3.不要覆盖基类中已经实现的方法:如果覆盖基类中已实现的方法,
那么你的基类就不是一个真正适合被继承的抽象,
基类中已实现的方法,应该由子类共享。
 
 
 
抽象工厂模式:
提供一个接口,用于创建相关或依赖对象的家族,
而不需要明确指定具体类。
 
使用对象的组合
 
 
允许客户使用抽象的接口来创建一组相关的产品,
而不需要知道实际产出的具体产品是什么。
客户和具体产品解耦。
 
 
oo principle
依赖抽象,不要依赖具体类。