- 浏览: 160874 次
- 性别:
- 来自: 成都
文章分类
- 全部博客 (134)
- JAVA Collection,Map (6)
- JAVA IO (6)
- JAVA 线程 (12)
- JAVA 反射机制 (6)
- JSP (2)
- JAVASCRIPT (6)
- JAVA OOP (4)
- Struts (4)
- Hibernate (5)
- Spring (9)
- IBatis (8)
- HTML (1)
- CSS (1)
- ORACLE (1)
- Servlet (4)
- DATABASE (5)
- JAVA逻辑 (1)
- JVM学习 (8)
- 设计模式 (13)
- JDBC (1)
- JAVA XML (6)
- Jquery (4)
- IT生活 (2)
- JAVA Web Servece (2)
- EJB (2)
- C语言基础 (3)
- JAVA数据结构和算法 (4)
- C数据结构和算法 (0)
- JAVA Collection (5)
- Map (5)
- Inner Class (1)
- JVM (0)
- tomcat (0)
- 版本控制 (1)
最新评论
-
baukh789:
...我们公司最近也在推这个东西,SVN用了四五年了,猛的换一 ...
git 初使用 -
BuN_Ny:
时序图???????????????????
EA入门-4 -
308202251:
308202251 写道308202251 写道3082022 ...
Java 反射机制中 getMethod()和getDeclaredField()区别 -
308202251:
308202251 写道308202251 写道3082022 ...
Java 反射机制中 getMethod()和getDeclaredField()区别 -
308202251:
308202251 写道308202251 写道3082022 ...
Java 反射机制中 getMethod()和getDeclaredField()区别
装饰者模式动态地将责任附加到对象上,若要扩展功能,装饰者模式提供了比集成更有弹性的体态方案。
1. 装饰者和被装饰对象有相同的超类型。
2. 可以用一个或多个装饰者包装一个对象。
3. 装饰者可以在所委托被装饰者的行为之前或之后,加上自己的行为,以达到特定的目的。
4. 对象可以在任何时候被装饰,所以可以在运行时动态的,不限量的用你喜欢的装饰者来装饰对象。
5. 装饰模式中使用继承的关键是想达到装饰者和被装饰对象的类型匹配,而不是获得其行为。
6. 装饰者一般对组件的客户是透明的,除非客户程序依赖于组件的具体类型。在实际项目中可以根据需要为装饰者添加新的行为,做到“半透明”装饰者。
7. 适配器模式的用意是改变对象的接口而不一定改变对象的性能,而装饰模式的用意是保持接口并增加对象的职责。
总结:装饰者模式是位了已有功能动态的添加更多功能的一种方式。当系统需要新功能的时候,是向旧功的类中添加新的代码。这些新加的代码通常装饰了原有类的核心职责或主要行为。
适用性:
以下情况使用Decorator模式
1. 需要扩展一个类的功能,或给一个类添加附加职责。
2. 需要动态的给一个对象添加功能,这些功能可以再动态的撤销。
3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能,从而使继承关系变的不现实。
4. 当不能采用生成子类的方法进行扩充时。一种情况是,可能有大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏,或类定义不能用于生成子类。
优点:
1. Decorator模式与继承关系的目的都是要扩展对象的功能,但是Decorator可以提供比继承更多的灵活性。
2. 通过使用不同的具体装饰类以及这些装饰类的排列组合,设计师可以创造出很多不同行为的组合。
缺点:
1. 这种比继承更加灵活机动的特性,也同时意味着更加多的复杂性。
2. 装饰模式会导致设计中出现许多小类,如果过度使用,会使程序变得很复杂。
3. 装饰模式是针对抽象组件(Component)类型编程。但是,如果你要针对具体组件编程时,就应该重新思考你的应用架构,以及装饰者是否合适。当然也可以改变Component接口,增加新的公开的行为,实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。
《Head First Design Patterns》对装饰者模式说的很清楚。这里稍微注意几点:
(1) 装饰者和被装饰者必须具有相同的超类型。
(2) 装饰者即可以包装被装饰者,也可以包装装饰者。往往利用多层包装来达到目的。
(3) 装饰者中组合了被装饰者对象,这是装饰类的关键特征。正是由于这种组合,使得我们能够随心所欲的通过嵌套装饰来动态扩展行为。
Java IO框架的装饰者设计
在java类库中的IO流就是用装饰者模式设计的。JDK5.0中60多个IO流类组成了四大家族:InputStream,OutputStream,Reader,Writer。
InputStream/OutputStream是对字节序列进行操作的抽象类。
Reader/Writer是基于Unicode代码单元进行操作的抽象类。
这四大家族中大量的类都具有自己不同的功能,要做到方便的完成各种输入输出行为。必须组合使用这些类,装饰者模式是再好不过的设计了。那么IO类库如何实现装饰者模式的,我们看看几个类的部分源码:
这四个类同属于InputStream家族,他们就是一个经典的装饰器模式设计。其中
InputStream 具有读入功能的抽象被装饰器。
FileInputStream 具有读入文件功能的具体被装饰器
FilterInputStream 具备装饰器的抽象意义。
BufferedInputStream 具有具体功能(缓冲功能)的装饰器。
这个时候后我想设计一个具有缓冲功能的读取文件中的字节的行为:
Java Collection框架的装饰者设计
在JDK类库种,集合类也使用了这种设计模式,我们看看这种设计模式给集合类库带来了什么好处?
问题提出:当我们即需要List结构的可重复存储,又需要Set中高效率的查找操作。怎么办?
最好的解决办法就是:先用List存储好所有的数据,当需要查找某个元素的时候,将List对象包装成Set类型进行查找,然后返回List数据结构和Set的查找结果。将两种不同类别的功能合并使用,装饰者模式(包装器)无疑是最好的设计。
所有实现Collection接口的集合类都有一种构造器,其参数是集合类的引用。
我们可以通过这种构造直接将一种Collection类对象包装成另一种。
值得注意的是:包装过程中集合类的存储数据类型必须兼容Collection<? extends E>。也就是被 包装 集合中数据类型必须是包装集合数据类型的子类或两者类型相同 。例如:被包装的ArrayList中的数据类型是Manager,它是包装的HashSet中数据类型Employee的子类。否则编译器不会通过。 这也是为了保证类型的自动向上转型的特性。被包装的类型可以通过包装操作自动向上转型成父类。
顺便提一句: 集合框架中的Map类型是不能和Collection类型互相包装的,他们的数据结构毕竟相差太大了 。(~你不想在商店买到的可乐里包装的是医用酒精吧)
这里提一下我一直的疑问:Collection的名字有点让人费解,刚学的时候还以为他就是所有集合类的基础接口,毕竟Collection的中文意思就是集合吗? 后来发现Map类型和
Collection没有一点关系,不知道Java的设计者是怎么取名字的,或者有难言之隐吧。
数组转化为集合:Array的asList()。
String[] values=".....";
HashSet<String> hs=new HashSet<String>(Array.asList(values));
集合转化为数组:Collection的toArray()。
HashSet<String> hs=new HashSet<String>();
Object[] o=hs.toArray();
千万要注意:toArray()方法返回的是一个Object[]数组。而且你无法将其强制类型转化成你需要的数组类型。(关于类类型间的强制类型转换,我在《【解惑】Java类型间的转型 》一文中有详细阐述)
String[] array=(String[])hs.toArray(); //error
我们必须使用toArray的变体来做到这一点,为toArray传递一个长度为0的随意类型的数组。然后,返回的数组就是这个类型了。
String[] array=hs.toArray(new String[0]);
1. 装饰者和被装饰对象有相同的超类型。
2. 可以用一个或多个装饰者包装一个对象。
3. 装饰者可以在所委托被装饰者的行为之前或之后,加上自己的行为,以达到特定的目的。
4. 对象可以在任何时候被装饰,所以可以在运行时动态的,不限量的用你喜欢的装饰者来装饰对象。
5. 装饰模式中使用继承的关键是想达到装饰者和被装饰对象的类型匹配,而不是获得其行为。
6. 装饰者一般对组件的客户是透明的,除非客户程序依赖于组件的具体类型。在实际项目中可以根据需要为装饰者添加新的行为,做到“半透明”装饰者。
7. 适配器模式的用意是改变对象的接口而不一定改变对象的性能,而装饰模式的用意是保持接口并增加对象的职责。
package com.jelly.decorator; /** * 定义一个对象接口,可以给这些对象动态地添加职责 * * @author Jelly QQ:136179492 * */ public abstract class Component { public abstract void operation(); } /** * 定义一个对象,可以给这个对象添加一些职责 * @author Jelly QQ:136179492 * */ public class ConcreteComponent extends Component { public void operation() { System.out.println("具体对象的操作"); } } /** * 装饰者 * 维持一个指向Component对象的引用,并定义一个与 Component接口一致的接口。 * * @author Jelly QQ:136179492 * */ public class Decorator extends Component { private Component component; public void setComponent(Component component) { this.component = component; } public void operation() { if (null != component) { component.operation(); } } } public class ConcreteDecoratorA extends Decorator { private String addedState; @Override public void operation() { super.operation(); addedState = "New State"; System.out.println(addedState); System.out.println("具体装饰对象A的操作"); } } public class ConcreteDecoratorB extends Decorator { @Override public void operation() { super.operation(); addedBehavior(); System.out.println("具体装饰对象B的操作"); } public void addedBehavior() { System.out.println("ConcreteDecoratorB操作"); } } public class Test { public static void main(String[] args) { ConcreteComponent c = new ConcreteComponent(); ConcreteDecoratorA d1 = new ConcreteDecoratorA(); ConcreteDecoratorB d2 = new ConcreteDecoratorB(); d1.setComponent(c); d2.setComponent(d1); d2.operation(); } }
总结:装饰者模式是位了已有功能动态的添加更多功能的一种方式。当系统需要新功能的时候,是向旧功的类中添加新的代码。这些新加的代码通常装饰了原有类的核心职责或主要行为。
适用性:
以下情况使用Decorator模式
1. 需要扩展一个类的功能,或给一个类添加附加职责。
2. 需要动态的给一个对象添加功能,这些功能可以再动态的撤销。
3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能,从而使继承关系变的不现实。
4. 当不能采用生成子类的方法进行扩充时。一种情况是,可能有大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏,或类定义不能用于生成子类。
优点:
1. Decorator模式与继承关系的目的都是要扩展对象的功能,但是Decorator可以提供比继承更多的灵活性。
2. 通过使用不同的具体装饰类以及这些装饰类的排列组合,设计师可以创造出很多不同行为的组合。
缺点:
1. 这种比继承更加灵活机动的特性,也同时意味着更加多的复杂性。
2. 装饰模式会导致设计中出现许多小类,如果过度使用,会使程序变得很复杂。
3. 装饰模式是针对抽象组件(Component)类型编程。但是,如果你要针对具体组件编程时,就应该重新思考你的应用架构,以及装饰者是否合适。当然也可以改变Component接口,增加新的公开的行为,实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。
《Head First Design Patterns》对装饰者模式说的很清楚。这里稍微注意几点:
(1) 装饰者和被装饰者必须具有相同的超类型。
(2) 装饰者即可以包装被装饰者,也可以包装装饰者。往往利用多层包装来达到目的。
(3) 装饰者中组合了被装饰者对象,这是装饰类的关键特征。正是由于这种组合,使得我们能够随心所欲的通过嵌套装饰来动态扩展行为。
Java IO框架的装饰者设计
在java类库中的IO流就是用装饰者模式设计的。JDK5.0中60多个IO流类组成了四大家族:InputStream,OutputStream,Reader,Writer。
InputStream/OutputStream是对字节序列进行操作的抽象类。
Reader/Writer是基于Unicode代码单元进行操作的抽象类。
这四大家族中大量的类都具有自己不同的功能,要做到方便的完成各种输入输出行为。必须组合使用这些类,装饰者模式是再好不过的设计了。那么IO类库如何实现装饰者模式的,我们看看几个类的部分源码:
//InputStream:字节序列输入类鼻祖 public abstract class InputStream implements Closeable { //最基本的读取字节的抽象方法,供子类扩展。 public abstract int read() throws IOException; } //FileInputStream: 读取文件中的字节流类 继承InputStream public class FileInputStream extends InputStream{ //构造器 public FileInputStream(String name) throws FileNotFoundException{ //....... } //本地方法,与操作系统低层交互的具体读入方法 public native int read() throwsIOException; } //FilterInputStream: 过滤流类,起装饰器作用,用于对输入装配各种功能 public class FilterInputStream extends InputStream { //用于记录被装饰者,也就是需要装配新功能的InputStream对象 protected volatile InputStream in; protected FilterInputStream(InputStream in) { //构造装饰器 this.in = in; //设置需要被包装InputStream对象 } //读入字节 public int read() throws IOException { return in.read(); } } //BufferedInputStream: 使输入流具有缓冲功能,是一种可以装配缓冲功能的装饰器,继承FilterInputStream public class BufferedInputStream extends FilterInputStream { //构造器 public BufferedInputStream(InputStream in) { this(in, defaultBufferSize); //in就是被装配缓冲功能的InputStream } }
这四个类同属于InputStream家族,他们就是一个经典的装饰器模式设计。其中
InputStream 具有读入功能的抽象被装饰器。
FileInputStream 具有读入文件功能的具体被装饰器
FilterInputStream 具备装饰器的抽象意义。
BufferedInputStream 具有具体功能(缓冲功能)的装饰器。
这个时候后我想设计一个具有缓冲功能的读取文件中的字节的行为:
public void IOTest{ //缓冲装饰器包装文件字节输入流 BufferedInputStream bis=new BufferedInputStream(new FileInputStream("C://decorator.txt")); //读取内容 bis.read(); }IO类库中还有很多其他的装饰器,比如处理基本数据类型的DataInputStream,处理ZIP文件流的ZipInputStream,等等。只要我们想的到的行为,都可以用这些装饰器包装组合来完成。就这一点,装饰器绝对是Perfect。
Java Collection框架的装饰者设计
在JDK类库种,集合类也使用了这种设计模式,我们看看这种设计模式给集合类库带来了什么好处?
问题提出:当我们即需要List结构的可重复存储,又需要Set中高效率的查找操作。怎么办?
最好的解决办法就是:先用List存储好所有的数据,当需要查找某个元素的时候,将List对象包装成Set类型进行查找,然后返回List数据结构和Set的查找结果。将两种不同类别的功能合并使用,装饰者模式(包装器)无疑是最好的设计。
所有实现Collection接口的集合类都有一种构造器,其参数是集合类的引用。
//ArrayList的包装构造器 public ArrayList(Collection<? extends E> c) { ..... } //LinkedList的包装构造器 public LinkedList(Collection<? extends E> c) { ..... } //HashSet的包装构造器 public HashSet(Collection<? extends E> c) { ..... }
我们可以通过这种构造直接将一种Collection类对象包装成另一种。
//Collection类的打包过程 import java.util.*; public class TestDemo{ public static void main(String[] args){ ArrayList<String> list=new ArrayList<String>(); list.add("a1"); list.add("a1"); list.add("b1"); list.add("c1"); System.out.println("List ="+list); HashSet<String> set=new HashSet<String>(list); //包装 System.out.println("Set ="+set); } } /*运行结果: List =[a1, a1, b1, c1] Set =[b1, a1, c1] */
值得注意的是:包装过程中集合类的存储数据类型必须兼容Collection<? extends E>。也就是被 包装 集合中数据类型必须是包装集合数据类型的子类或两者类型相同 。例如:被包装的ArrayList中的数据类型是Manager,它是包装的HashSet中数据类型Employee的子类。否则编译器不会通过。 这也是为了保证类型的自动向上转型的特性。被包装的类型可以通过包装操作自动向上转型成父类。
//包装过程中泛型类型的兼容 import java.util.*; class Employee{ } class Manager extends Employee{ } public class TestDemo{ public static void main(String[] args){ /*error : ArrayList<Employee> list=new ArrayList<Employee>(); HashSet<Manager> set=new HashSet<Manager>(list);*/ //正确: ArrayList<Manager> list=new ArrayList<Manager>(); ashSet<Employee> set=new HashSet<Employee>(list); } }
顺便提一句: 集合框架中的Map类型是不能和Collection类型互相包装的,他们的数据结构毕竟相差太大了 。(~你不想在商店买到的可乐里包装的是医用酒精吧)
这里提一下我一直的疑问:Collection的名字有点让人费解,刚学的时候还以为他就是所有集合类的基础接口,毕竟Collection的中文意思就是集合吗? 后来发现Map类型和
Collection没有一点关系,不知道Java的设计者是怎么取名字的,或者有难言之隐吧。
数组转化为集合:Array的asList()。
String[] values=".....";
HashSet<String> hs=new HashSet<String>(Array.asList(values));
集合转化为数组:Collection的toArray()。
HashSet<String> hs=new HashSet<String>();
Object[] o=hs.toArray();
千万要注意:toArray()方法返回的是一个Object[]数组。而且你无法将其强制类型转化成你需要的数组类型。(关于类类型间的强制类型转换,我在《【解惑】Java类型间的转型 》一文中有详细阐述)
String[] array=(String[])hs.toArray(); //error
我们必须使用toArray的变体来做到这一点,为toArray传递一个长度为0的随意类型的数组。然后,返回的数组就是这个类型了。
String[] array=hs.toArray(new String[0]);
发表评论
-
一个项目的开发过程(转)
2011-09-29 23:55 7891、项目启动 1)、项目组成立(公司成员、客户成员)2)、 ... -
代理模式 Proxy
2011-09-13 21:47 818代理模式:给某一对象提供代理对象,并由代理对象控制具体对象的引 ... -
策略模式
2011-09-10 17:01 791抽象策略角色: 策略类,通常由一个接口或者抽象类实现。 ... -
简单工厂模式
2011-09-03 19:32 748优点 :工厂类是整个模式的关键.包含了必要的逻辑判断,根据 ... -
状态图和活动图区别
2011-08-30 17:01 1359状态图是描述某一对象的状态转化的,它主要表现的是该对象的状态。 ... -
UML建模之状态图(Statechart Diagram)
2011-08-29 15:07 1471一、状态图简介(Brief introduction) ... -
EA入门-4
2011-08-29 13:49 317211.2. 时序图的绘制 ... -
EA入门-3
2011-08-29 13:48 1204八. 文档的生成 8 ... -
EA入门-2
2011-08-29 13:48 1346四. Class 模型 ... -
EA入门-1
2011-08-29 13:47 1507生命周期软件设计方案——Enterprise Architec ... -
UML用例图中包含(include)、扩展(extend)和泛化(generalization)三种关系详解
2011-08-09 21:12 709共性:都是从现有的用 ... -
UML用例图之泛化(generalization)、扩展(extend)和包含(include)关系--UML一波流系列讲解
2011-03-14 22:49 1655在画用例图的时候,理 ...
相关推荐
装饰者模式是软件设计模式中的一种结构型模式,它的主要目的是动态地给对象添加新的功能,而无需修改原有代码。在Java中,装饰者模式通常通过继承和组合来实现,它提供了一种比继承更灵活的方式来扩展对象的功能。...
装饰者模式是面向对象设计模式的一种,主要用于动态地给一个对象添加一些额外的职责,而不会改变该对象的类。这种模式允许我们独立于对象的类来扩展其功能,为对象增加新的行为或属性,同时保持了代码的可读性和可...
装饰者模式是设计模式的一种,属于结构型模式,它的主要目的是动态地给对象添加新的行为或职责,而无需改变对象的原始代码。在Android开发中,装饰者模式的应用相当广泛,尤其是在视图组件的扩展和功能增强上。下面...
装饰者模式是一种结构型设计模式,它允许在运行时向对象添加新的行为或职责,而无需修改对象本身。这种模式的核心思想是通过将对象包装在一个装饰类中来扩展功能,而不是通过继承。以下是对装饰者模式的详细阐述: ...
装饰者模式(Decorator Pattern)是设计模式中的一种结构型模式,它允许在运行时动态地给对象添加新的职责,而不必修改原有代码,遵循“开闭原则”。在Java中,装饰者模式通常通过继承和组合来实现,尤其适用于那些...
装饰者模式是面向对象设计模式中的一个重要概念,它在C#等编程语言中广泛应用。这个例子以星巴克咖啡为例,展示了如何使用装饰者模式来灵活地扩展对象的功能,而无需修改原有代码。 装饰者模式的核心思想是动态地将...
装饰者模式是软件设计模式中的一种结构型模式,它的主要目的是动态地给对象添加新的功能,而无需修改原有的代码。这种模式遵循开闭原则,即对扩展开放,对修改关闭,使得我们可以在不改变对象原有结构的情况下,通过...
**Qt设计模式之装饰者模式** 装饰者模式(Decorator Pattern)是软件设计模式中的结构型模式之一,它允许在运行时动态地给一个对象添加新的行为或职责,而无需修改对象本身。在Qt库中,装饰者模式也被广泛应用,...
装饰者模式是一种设计模式,它允许我们向一个对象动态地添加新的行为或责任,而无需修改对象本身的代码。在C++中实现装饰者模式,我们可以遵循以下步骤和关键概念: 1. **定义接口**:首先,我们需要定义一个基础...
装饰者模式是软件设计模式中的一种结构型模式,它的主要目的是动态地给对象添加新的功能,而无需修改原有的代码。这种模式遵循开闭原则,即对扩展开放,对修改关闭,使得我们的系统更加灵活,易于维护和扩展。 装饰...
装饰者模式是一种结构型设计模式,它允许在不修改对象本身的情况下动态地为对象添加新的行为和职责。这种模式在软件工程中广泛应用,因为它提供了一种灵活的方式来扩展对象的功能,而不会破坏其原有的结构。在Java、...
装饰者模式是设计模式中的一种结构型模式,它在不改变对象原有行为的基础上,动态地为对象添加新的功能。这种模式常被用于扩展或增强对象的功能,而无需修改原对象的代码,符合“开闭原则”。在Java的SSL(Secure ...
装饰者模式是一种结构型设计模式,它允许在运行时向对象添加新的行为或职责,而无需修改对象的源代码。这种模式在C++中的应用尤为广泛,因为它提供了灵活性,能够扩展对象的功能,同时保持代码的可读性和可维护性。 ...
装饰者模式(Decorator Pattern)是结构型设计模式之一,它允许在运行时向对象添加新的行为或职责,而无需修改对象的源代码。这个模式的名字来源于装饰艺术,它通过添加额外的装饰来增强一个物体的外观,同样地,...
装饰者模式是一种结构型设计模式,它允许在运行时向对象添加新的行为或职责,而无需修改对象的源代码。这种模式通过将对象包装在一个装饰类中来实现,装饰类与原类有相同的接口,因此可以透明地替换或增强原有对象的...
装饰者模式是面向对象设计中的一种行为设计模式,它允许在运行时动态地给对象添加新的职责或行为,而无需改变对象本身。在游戏设计中,装饰者模式常常被用来扩展角色、装备等对象的功能,使得游戏内容更加丰富且易于...
装饰者模式(Decorator Pattern)是一种结构型设计模式,它允许我们向对象添加新的行为或职责,而无需修改对象的原始代码。在C++中实现装饰者模式,可以让我们灵活地扩展对象的功能,同时保持代码的可读性和可维护性...
装饰者模式是面向对象设计中的一种经典模式,它在不修改已有对象的源代码或继承体系的情况下,通过组合的方式动态地给对象添加新的行为或职责。这种模式在实际开发中非常常见,尤其在需要灵活扩展功能,而又不想破坏...