设计模式(12)-装饰模式
思想:为一个对象已有的子类添加一些额外的职责。
场景:该模式的使用场景,主要是有的时候我们不愿意定义逻辑上新的子类,因为没有新的逻辑含义上的子类概念,而只是想为一个已存在的子类附加 一些职责。
实现:该 模式的实现主要就是定义一个物理上的新的子类,但是,它只是包含要附加职责的类,传递外部对相同接口的调用,在这个传递调用的通道上附加额外的功能。突然 想到,Decorator模式是不是一定程度上也能代替DynamicProxy模 式,从而成为一种AOP实现的方案呢?
思想:为一个对象已有的子类添加一些额外的职责。
场景:该模式的使用场景,主要是有的时候我们不愿意定义逻辑上新的子类,因为没有新的逻辑含义上的子类概念,而只是想为一个已存在的子类附加 一些职责。
实现:该 模式的实现主要就是定义一个物理上的新的子类,但是,它只是包含要附加职责的类,传递外部对相同接口的调用,在这个传递调用的通道上附加额外的功能。突然 想到,Decorator模式是不是一定程度上也能代替DynamicProxy模 式,从而成为一种AOP实现的方案呢?
思想:将 对象组合成树形结构以表示“部分-整体”的层次结构,使得用户对单个对象和组合对象的使用具有一致 性。
场景:该 模式的应用场景极其类似,比如像图形系统,如电路设计、UML建模系统,或者像web的 显示元素等,都是那种需要整体和部分具有使用接口上的一定的一致性的需求的结构,实际上,我觉得这样的系统如果不使用Composite模 式将会是惨不忍睹的。
思想:将一个类的接口转换成另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
场景:该 模式的应用场景太多了,很多需要的功能模块的接口和我们需要的不完全一致或者有多余或不足,但是需要和我们的系统协同工作,通过Adapter把 它包装一下就能让使它接口兼容了。
实现:定 义一个Adapter类,包含需要包装的类,实现需要的其它接口,调用被包装的类的方法来实现需要 的接口。
思想:为子系统中的一组接口提供一个一致的界面,这个接口使得这一子系统更加容易使用。
场景:当 你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性, 也更容易对子系统进行定制,但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可 以提供一个简单的缺省视图,这一视图对大多数用户来说已经足够,而那些需要更多的可定制性的用户可以越过Facade层。 客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他 的子系统分离,可以提高子系统的独立性和可移植性。当你需要构建一个层次结构的子系统时,使用Facade模 式定义子系统中每层的入口点。如果子系统之间是相互依赖的,你可以让它们仅通过Facade进行通 讯,从而简化了它们之间的依赖关系。(这里直接引用了《设计模式迷你手册》,因为觉得它确实已经说得很明了了,下面类似的情形我直接引用原文的就不再注明 了,这里先说明一下,感谢《手册》作者的这些优秀总结。当然,本文的绝大多数文字都是Teddy本 人的原创看法,绝非抄袭,您可以比较本文和附件《手册》,附件同时也会提供本文的Word版本下 载。)
实现:该 模式的实现需要定义一个新的系统构架上的Layer,该层向上提供一组新的接口,向下调用子系统原 有的接口。
定义面包类:
1 | <!-- more --> |
定义一个篮子,里边放一个数组存放面包:
1 | package ProducerAndConsumer; |
定义生产者者:
1 | package ProducerAndConsumer; |
定义消费者:
1 | package ProducerAndConsumer; |
测试类:
1 | package ProducerAndConsumer; |
数据
1 | 生产者1生产一个面包 |
思想:将一个类的创建过程和他的主体部分分离。
场景:该模式的典型的应用场景是:一个类的创建过程可能比较复杂,或者创建过程中的某些阶段可能会容易变化;或者多个类的创建过程比较类似, 但是主体不同。
思想:克 隆一个已有的类的实例(大家相比都用过甚至写过类的Clone实现,应该很容易理解了)。
场景:应 用Clone的场景应该说非常多,理想情况下我当然希望任何类都能Clone, 需要的时候就能Clone一份一模一样的出来。
工厂模式有三种:简单工厂模式,抽象工厂模式和工厂方法模式。
1、简单工厂模式