今天要搞清楚的问题是为什么需要上面那个被黄色框圈住的“抽象装饰器类”。
装饰器模式实现了不破坏原有类的情况下动态扩展一个类的功能。
“为什么需要抽象装饰器类”,搞清楚这个问题最好的办法是手写一个装饰器模式,然后去掉中间的抽象装饰器类,看看会发生什么。
下面根据最上面的UML图写一下代码:
// 顶层接口 public interface Shape { void draw(); void f1(); void f2(); }
下面是一个提供了抽象装饰器类的装饰器类实现方式:
// 抽象装饰器类 public abstract class ShapeDecorator implements Shape { protected Shape decoratedShape; public ShapeDecorator(Shape decoratedShape){ this.decoratedShape = decoratedShape; } public void draw(){ decoratedShape.draw(); } public void f1(){ decoratedShape.f1(); } public void f2(){ decoratedShape.f2(); } } //一个实际的装饰器类 public class RedShapeDecorator extends ShapeDecorator { public RedShapeDecorator(Shape decoratedShape) { super(decoratedShape); } // 这个类只想增强一下draw()方法,不想变动其他的f1,f2方法,所以这个类只需要重写这个类即可 public void draw() { decoratedShape.draw(); setRedBorder(decoratedShape); } private void setRedBorder(Shape decoratedShape){ System.out.println("Border Color: Red"); } }
下面是一个不提供抽象装饰器类的装饰器类实现方式:
//一个实际的装饰器类 public class RedShapeDecorator implements Shape { // 每多一个装饰器类,这里需要重复 private Shape decoratedShape; public RedShapeDecorator(Shape decoratedShape) { this.decoratedShape = decoratedShape; } public void draw() { decoratedShape.draw(); setRedBorder(decoratedShape); } private void setRedBorder(Shape decoratedShape){ System.out.println("Border Color: Red"); } //这个类仅仅想增强draw方法,但是因为实现的是顶层接口,不得不重写这个方法 public void f1(){ decoratedShape.f1(); } //这个类仅仅想增强draw方法,但是因为实现的是顶层接口,不得不重写这个方法 public void f2(){ decoratedShape.f2(); } }
结论:从上面的代码可以清晰的看出结果了,抽象装饰器器类的存在简化了真实装饰器类的写法。
原创文章,作者:geekgao,如若转载,请注明出处:https://www.geekgao.cn/archives/97