- 浏览: 314748 次
- 性别:
- 来自: 重庆
文章分类
- 全部博客 (286)
- 设计模式 (14)
- spring (5)
- 开发工具 (12)
- java (19)
- apache.commons工具 (7)
- ibaits (5)
- extjs4.0 (4)
- 数据库 (2)
- spring工具类 (2)
- jquery1.8 (32)
- 杂记 (1)
- linux (2)
- Quart (1)
- springMVC (2)
- webservice (1)
- oracle (5)
- dwr (6)
- jbmp3 (27)
- lucene3.5 (27)
- javascript (18)
- hibernate3.3.2 (27)
- spring事务管理 (10)
- nio (2)
- strust2 (3)
- jvm (7)
- jquery-easyui-1.2.6 (22)
- 多线程 (14)
- maven (3)
- 常用正则表达式 (4)
最新评论
-
HF_SKY000:
请问:
一、能否提供一下密钥库文件的生成方法?
二、密钥库的密 ...
Java sslSocket 聊天实例
MM们要过生日了 ,怎么也得表示下吧。最起码先送个蛋糕。蛋糕多种多样了。巧克力,冰淇淋,奶油等等。这都是基本的了 ,再加点额外的装饰,如蛋糕里放点花。放贺卡。放点干果吃着更香等等。看看我是如何设计的。
我想既然是蛋糕,那我就把蛋糕作为一个抽象类,剩下的蛋糕子类型来继承它,每个子类都有吃该蛋糕的感觉 ^_^,看起来真的不错。蛋糕的子类分别是奶酪蛋糕,巧克力蛋糕,冰淇淋蛋糕,插花的冰淇淋蛋糕,放贺卡的冰淇淋蛋糕。某个MM的生日蛋糕喜欢带花的冰淇淋蛋糕。还好我早有准备。但是有几次失策了。。她们要的蛋糕我这都没有。比如带鲜花的巧克力蛋糕。带果仁的牛奶蛋糕。带鲜花带果仁的蛋糕。。。。那我还要继续添加蛋糕的子类。。问题出现了。这样会造成大量的蛋糕子类 。真是噩梦啊。
那么我要好好思考这个问题了。发现了刚才的设计确实有问题。。发现了真正的要关注的主体是蛋糕。。而贺卡,花,果仁等等只不过是装饰 的作用。
思路来了。蛋糕作为主体,其他的东西都加到蛋糕上。MM要啥我就加啥呗。呵呵。
到现在我们要明确的是:
- 蛋糕是主体。
- 花,贺卡,果仁等等是装饰者。
- 可以用装饰者包装蛋糕。
来看看什么是装饰器模式吧:
动态的将责任附加到对象上,若要扩展功能,装饰者提供了比继承更有弹性的替代方案。
- Component:抽象出的主体对象。
- ConcreteComponent:是要动态扩展的对象,它继承自Component.
- Decorator:是装饰器的接口。(这里的接口并不是指java的interface)。
- ConcreteDecoratorA:实现Decorator的类,包含了一个Component引用,这样就可以扩展Component的方法了。
说完理论了。可能还一头雾水吧。。。还是接着蛋糕的例子继续说。先看图吧。
基本符合了上面所提到的装饰者模式的框架结构了。再看看代码:
Cake
- package decorator.demo;
- /**
- * 蛋糕基类
- * @author Nicholas
- *
- */
- public abstract class Cake {
- String remark = "蛋糕";
- public String getRemark() {
- return remark;
- }
- public abstract String getImpression();//用来描述吃蛋糕的感觉。。。。
- }
package decorator.demo; /** * 蛋糕基类 * @author Nicholas * */ public abstract class Cake { String remark = "蛋糕"; public String getRemark() { return remark; } public abstract String getImpression();//用来描述吃蛋糕的感觉。。。。 }
Cake是个抽象类,它已经实现了getRemark的方法。但没有实现getImpression.这个方法必须被子类实现。
再看看装饰器的抽象类
OtherDecorator
- package decorator.demo;
- /**
- * 其他用来添加蛋糕的东西
- * @author Nicholas
- *
- */
- public abstract class OtherDecorator extends Cake{
- Cake cake;
- /**
- * 引用一个Cake.
- * 让被装饰者进入装饰者之中。这里用的是构造方法注入。
- * 这样就可以调用Cake实例的方法了。
- * @param cake
- */
- public OtherDecorator(Cake cake){
- this.cake=cake;
- }
- /**
- * 让装饰器的子类都去实现getRemark方法。业务需要每个装饰器都要有描述。
- */
- public abstract String getRemark();
- }
package decorator.demo; /** * 其他用来添加蛋糕的东西 * @author Nicholas * */ public abstract class OtherDecorator extends Cake{ Cake cake; /** * 引用一个Cake. * 让被装饰者进入装饰者之中。这里用的是构造方法注入。 * 这样就可以调用Cake实例的方法了。 * @param cake */ public OtherDecorator(Cake cake){ this.cake=cake; } /** * 让装饰器的子类都去实现getRemark方法。业务需要每个装饰器都要有描述。 */ public abstract String getRemark(); }
下面让我们实现一个蛋糕吧。^_^。。
- package decorator.demo;
- /**
- * 乳酪蛋糕
- * @author Nicholas
- *
- */
- public class CheeseCake extends Cake{
- /**
- * 乳酪蛋糕的构造方法
- */
- public CheeseCake(){
- super.remark="乳酪蛋糕";//修改乳酪蛋糕的描述。
- }
- /**
- * 实现了Cake抽象类的getImpression
- * 吃乳酪蛋糕的感觉。。
- */
- public String getImpression() {
- return "香甜感受";
- }
- }
package decorator.demo; /** * 乳酪蛋糕 * @author Nicholas * */ public class CheeseCake extends Cake{ /** * 乳酪蛋糕的构造方法 */ public CheeseCake(){ super.remark="乳酪蛋糕";//修改乳酪蛋糕的描述。 } /** * 实现了Cake抽象类的getImpression * 吃乳酪蛋糕的感觉。。 */ public String getImpression() { return "香甜感受"; } }
其他实现Cake的类就不列出了,道理是一样的。
下面我们要开始实现具体的装饰器了。
- package decorator.demo;
- /**
- * 给蛋糕添加的花
- * @author Nicholas
- *
- */
- public class FlowerDecorator extends OtherDecorator{
- /**
- * 构造函数
- * 传入一个cake实例,也就是前面所实现的Cake的子类,如奶酪蛋糕,巧克力蛋糕等等。
- * @param cake
- */
- public FlowerDecorator(Cake cake){
- super(cake);//调用父类的构造方法,可以获取Cake的实例了。就可以调用Cake实例的方法.
- super.remark="一朵玫瑰花";
- }
- /**
- * 实现了装饰器抽象类的getImpression方法。
- */
- public String getImpression() {
- //这是重点。我们通过构造方法传入的cake实例。对cake进行了装饰,增加了新的功能。
- return cake.getImpression()+","+"看到一朵花真是happy";
- }
- public String getRemark() {
- return cake.getRemark()+"+"+super.remark;
- }
- }
package decorator.demo; /** * 给蛋糕添加的花 * @author Nicholas * */ public class FlowerDecorator extends OtherDecorator{ /** * 构造函数 * 传入一个cake实例,也就是前面所实现的Cake的子类,如奶酪蛋糕,巧克力蛋糕等等。 * @param cake */ public FlowerDecorator(Cake cake){ super(cake);//调用父类的构造方法,可以获取Cake的实例了。就可以调用Cake实例的方法. super.remark="一朵玫瑰花"; } /** * 实现了装饰器抽象类的getImpression方法。 */ public String getImpression() { //这是重点。我们通过构造方法传入的cake实例。对cake进行了装饰,增加了新的功能。 return cake.getImpression()+","+"看到一朵花真是happy"; } public String getRemark() { return cake.getRemark()+"+"+super.remark; } }
到现在终于大功告成了。。这样方便了很多,可以通过装饰器生成很多种类的蛋糕。
- package decorator.demo;
- public class MyGirlB {
- public static void main(String[] args){
- //用果仁,花包装巧克力蛋糕。
- Cake nutsFlowerChocolateCake = new NutsDecorator(new FlowerDecorator(new ChocolateCake()));
- System.out.println("remark "+nutsFlowerChocolateCake.getRemark());
- //吃蛋糕的感受已经发生了改变。
- System.out.println("impression "+nutsFlowerChocolateCake.getImpression());
- }
- }
package decorator.demo; public class MyGirlB { public static void main(String[] args){ //用果仁,花包装巧克力蛋糕。 Cake nutsFlowerChocolateCake = new NutsDecorator(new FlowerDecorator(new ChocolateCake())); System.out.println("remark "+nutsFlowerChocolateCake.getRemark()); //吃蛋糕的感受已经发生了改变。 System.out.println("impression "+nutsFlowerChocolateCake.getImpression()); } }
这个模式的缺点也挺明显的 ,看看如下图片
为了扩展cake的功能,加入了许多的装饰类。。当然用户也可以继承OtherDecorator来继续扩展。但是对API使用者是个困扰。。所以API要说明哪些类是用来包装的。。
发表评论
文章已被作者锁定,不允许评论。
-
中介者模式
2012-07-30 14:45 876<!--StartFragment--> 抽象中 ... -
原型模式
2012-07-30 13:09 861<!--StartFragment--> ... -
状态模式
2012-07-30 10:50 953State模式的定义: 不同的状态,不同的行为;或者说,每个状 ... -
访问者模式
2012-07-28 12:35 1056<!--StartFragment--> & ... -
责任链模式
2012-07-26 17:35 805抽象处理者 package ChainOfResponsib ... -
观察者模式
2012-07-26 17:24 592观察者: package ObserverPattern.o ... -
组合模式
2012-07-26 14:45 999<!--StartFragment--> ... -
工厂模式
2012-06-25 20:41 841一、引子话说十年前,有一个爆发户,他家有三辆汽车(Benz(奔 ... -
单例模式
2012-06-25 20:38 972前面说提到的五种创建模式,主要解决的问题是如何创建对象,获得产 ... -
命令模式
2012-06-25 18:03 1073Command模式(命令) Java深入到一定程度,就不可 ... -
桥梁模式
2012-06-25 11:32 1133桥梁模式的用意是将问题的抽象和实现分离开来实现,通过用聚合代替 ... -
策略模式
2012-06-16 00:10 869本文探讨初学使用策略模式时遇到的一些疑惑,以及在工作中慢慢解决 ... -
建造者模式
2012-06-07 10:34 852Builder模式也叫建造者模式或者生成器模式,是由GoF提出 ...
相关推荐
### 开发模式之装饰模式详解 #### 装饰模式定义 装饰模式(Decorator Pattern)是一种结构型设计模式,允许向对象动态地添加新的功能,而无需修改其原有结构。这种模式通过创建一个新的包装类来包裹真实的对象,...
装饰模式是一种设计模式,它允许我们在不修改原有对象的基础上,通过添加新的行为或属性来扩展对象的功能。在"装饰模式小猪快跑游戏模拟"这个实例中,我们看到这种模式被巧妙地应用到了一个名为“小猪吃苹果”的游戏...
装饰模式是一种结构型设计模式,它允许我们向一个对象动态地添加新的行为或责任,而无需修改该对象的源代码。在C#中,装饰模式是通过创建一个包装类(Decorator),该包装类实现了与被装饰对象相同的接口,并持有被...
【装饰模式】是一种设计模式,源自Erich Gamma等人编写的《设计模式:可重用面向对象软件的基础》一书。这种模式在Swing开发中尤为常见,用于增强或改进现有对象的功能,尤其在Web应用程序中,如Java的J2EE环境,...
装饰模式是一种设计模式,属于结构型模式,其主要目的是在不改变对象本身的基础上,通过向对象添加新的行为或属性来扩展其功能。这种模式遵循“开闭原则”,即对扩展开放,对修改关闭。 在装饰模式中,有四个关键...
装饰模式是一种结构型设计模式,它允许在运行时给对象添加新的行为或责任,而无需修改对象的源代码。在Java中,装饰模式通常通过继承和组合来实现,提供了比子类化更灵活的方式来扩展对象的功能。 装饰模式的核心...
装饰模式是一种结构型设计模式,它允许在运行时向对象添加新的行为或责任,而无需修改对象的源代码。这种模式在软件工程中非常常见,因为它提供了灵活性,使得我们可以独立于对象的组合来扩展功能。 在C++中,装饰...
装饰模式是一种结构型设计模式,它允许在运行时动态地给对象添加新的行为或属性,而不必修改原有类的代码。这种模式的核心在于装饰者和组件接口的统一,使得装饰者可以替代原对象并添加额外的功能。在"设计模式之...
装饰模式(Decorator)是软件设计领域中一种非常实用的结构型设计模式,它允许我们向一个对象添加新的行为或责任,而无需修改该对象的源代码。在C++编程语言中,装饰模式常用于动态地扩展类的功能,使得类的行为在...
装饰模式是一种设计模式,它允许在运行时向对象添加新的行为或责任,而无需修改对象的源代码。这种模式在不违背开闭原则(对扩展开放,对修改关闭)的前提下,提供了灵活的扩展机制。装饰模式通常用于为已有对象添加...
装饰模式(Decorator Pattern)是设计模式中的一种结构型模式,它在不改变原有对象的基础上,通过添加额外的职责来扩展对象的功能。在C#中,装饰模式尤其适用于那些需要动态地增加或减少对象功能的情况,避免了使用...
装饰模式是一种设计模式,它允许在不改变对象自身的情况下,动态地给对象添加新的行为或职责。这种模式常用于在不修改源代码的情况下扩展对象的功能,或者为对象提供额外的职责。在本例中,"项目经理接到一个项目,...
装饰模式是一种设计模式,它允许我们在不改变对象本身的情况下,为对象添加新的行为或属性,从而扩展其功能。这种模式遵循“开闭原则”,即对扩展开放,对修改关闭,这意味着我们可以灵活地增加一个对象的功能,而...
装饰模式是一种结构型设计模式,它允许我们向现有的对象添加新的功能,同时又不破坏其原有的结构。在C#中,装饰模式常用于在运行时动态地改变对象的行为,而无需修改原始类的代码。这种模式的核心在于装饰者类与被...
装饰模式是一种设计模式,它允许在运行时向对象添加新的行为或职责,而无需修改对象的源代码。这种模式在软件工程中非常有用,因为它提供了灵活性,使得代码可以在不破坏封装性的前提下进行扩展。 在"实验九:装饰...
装饰模式是一种设计模式,它允许在不修改对象本身的情况下,通过包装(或“装饰”)对象来动态地扩展其功能。在面向切面编程(Aspect Oriented Programming, AOP)中,装饰模式常被用来实现在运行时向目标对象添加...
装饰模式是一种结构型设计模式,它允许在运行时向对象添加新的行为或责任,而无需修改对象的源代码。这种模式通常用于保持对象的原始类结构不变,同时增强其功能。HeadFirst 设计模式系列书籍以其生动有趣的插图和...
装饰模式是一种结构型设计模式,它允许我们向对象添加新的行为或责任,而无需修改对象的源代码。这种模式在不违背开闭原则(对扩展开放,对修改关闭)的前提下,提供了灵活的扩展机制。在《Head First设计模式》一书...
装饰模式是一种结构型设计模式,它是面向对象设计中用来动态添加或修改对象功能的一种方法。在软件工程中,装饰模式允许我们向一个现有的对象添加新的行为或职责,同时又不改变其原有的结构,从而实现对类的功能扩展...
装饰模式是一种设计模式,它允许在运行时向对象添加新的行为或责任,而无需修改对象的源代码。这种模式在Java等面向对象编程语言中非常常见,因为它提供了灵活性,使得扩展对象的功能变得容易且优雅。在这个"装饰...