程序员:
* T恤/polo+牛仔裤+运动鞋
//程序员
public interface Programmer {
public void show();
}
//我 shilvfei
public class Shilvfei implements Programmer{
@Override
public void show() {
// TODO Auto-generated method stub
System.out.println("我是一个程序员");
}
}
// 这个类就是穿着的抽象类(也就是装饰的抽象类)
public abstract class Decorator implements Programmer{
protected Programmer programmer;
//给shilvfei穿衣
public void dress(Programmer programmer){
this.programmer = programmer;
}
@Override
public void show() {
// TODO Auto-generated method stub
if(programmer!=null){
programmer.show();
}
}
}
//T恤
public class Tshirt extends Decorator{
@Override
public void show() {
// TODO Auto-generated method stub
super.show();
System.out.println("穿着T恤");
}
}
//牛仔裤
public class Jeans extends Decorator {
@Override
public void show() {
// TODO Auto-generated method stub
super.show();
System.out.println("牛仔裤");
}
}
//运动鞋
public class GymShoes extends Decorator{
@Override
public void show() {
// TODO Auto-generated method stub
super.show();
System.out.println("穿上运动鞋");
}
}
//开始穿衣
public class DecoratorTest {
public static void main(String[] args) {
Programmer shilvfei = new Shilvfei();
Decorator tShirt = new Tshirt();
Decorator jeans = new Jeans();
Decorator gymShoes = new GymShoes();
//首先确定穿在谁身上
tShirt.dress(shilvfei);
//穿完T恤的程序员,再穿上牛仔裤
jeans.dress(tShirt);
//穿完牛仔裤的程序员,再穿上运动鞋
gymShoes.dress(jeans);
//show一下
gymShoes.show();
}
}
输出结果:
我是一个程序员
穿着T恤
牛仔裤
穿上运动鞋
UML:
装饰模式: 动态地给一个对象添加一些额外的职责,就能增加功能来说,装饰者模式比生成子类更为灵活.
原有的设计中,当系统需要新功能的时候,是向旧的类中添加新的代码。这些新加的代码通常装饰了原有类的核心职责或主要行为。然后这种做法的问题在于,它们在主类中加入了新的字段,新的方法和新的逻辑,从而增加了主类的复杂度,而这些新加入的东西仅仅是为了满足一些只在某种特定情况下才会执行的特殊行为的需要。而装饰模式却提供了一个非常好的解决方案,它把每个要装饰的功能放在单独的类中,并让这个类包装它所要装饰的对象,因此,当需要执行特殊行为时,客户代码就可以在运行时根据需要有选择地、按顺序地使用装饰功能包装对象了。