装饰者模式

定义

动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。

通用类图

意图

动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。

优点

1. 装饰类和被装饰类可以独立发展，而不会相互耦合。
2. 装饰模式是继承关系的一个替代方案。
3. 装饰模式可以动态地扩展一个实现类的功能。

缺点

多层装饰容易导致问题，尽量减少装饰类的数量，以便降低系统的复杂度。

应用场景

1. 需要扩展一个类的功能，或给一个类增加附加功能。
2. 需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
3. 需要为一批的兄弟类进行改装或加装功能。

扩展

说明

装饰模式是对继承的有力补充。要知道继承不是万能的，继承可以解决实际的问题，但是在项目中你要考虑诸如易维护、易扩展、易复用等，而且在一些情况下要是用继承就会增加很多子类，而且灵活性非常差，那当然维护也不容易，也就是说装饰模式可以替代继承，解决我们类膨胀的问题。同时，继承是静态地给类增加功能，而装饰模式则是动态地增加功能。

实践

下面结合spring项目对装饰者模式举一个简单的例子。

1.Controller

@RestController
public class HotelController {@Resourceprivate HotelManager hotelManager;@GetMapping("/listHotel")public String listHotel() {return JSON.toJSONString(hotelManager.listHotel());}}

有一个controller，接收一个 listHotel 的 get 请求，调用 hotelManager （service层）的 listHotel() 接口。

2.Service

public interface HotelManager {List<Hotel> listHotel();}@Service("hotelManager")
public class HotelManagerImpl implements HotelManager {@Resourceprivate HotelDao hotelDao;@Overridepublic List<Hotel> listHotel() {try {Thread.sleep(3000);} catch (InterruptedException e) {e.printStackTrace();}return hotelDao.listHotel();}
}

hotelManager 的 listHotel 接口直接调用 hotelDao 的 listHotel() 接口，从数据库中查询数据。这里 Thread.sleep(3000) 为了模拟从数据库查询数据返回比较慢的情况。

这是在java web应用开发中一个很简单的，从前端接收一个请求到数据库查询数据返回给前端的一个动作。当这个查询效率非常低，耗时非常多，但是数据又不会经常变的情况下，我们可以通过把数据放到缓存（redis memcached等）里面来提高查询效率。

如果在项目进度非常紧的情况下，我们很可能写出下面的代码

public List<Hotel> listHotel() {if (在redis中可以查询到结果) {return redis.get(结果)} else {try {Thread.sleep(3000);} catch (InterruptedException e) {e.printStackTrace();}return hotelDao.listHotel();}}

首先非常丑，其次多余的代码和业务逻辑混在一起，让人不能一眼就看清这个接口做了什么事情。

接下来通过装饰者模式重构一下
增加一个自定义注解

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface RedisCache {
}

这是一个空的方法级别的注解，表示被该注解标示的方法返回的数据都应缓存在redis。

恢复 hotelManager.listHotel() 方法并且头上加入自定义注解

@RedisCache
@Override
public List<Hotel> listHotel() {try {Thread.sleep(3000);} catch (InterruptedException e) {e.printStackTrace();}return hotelDao.listHotel();
}

新建一个 HotelManagerDecorate 类

public class HotelManagerDecorate {private HotelManager hotelManager;private RedisTemplate redisTemplate;public List<Hotel> listHotel() throws Exception{Method method = Util.getTarget(hotelManager).getClass().getDeclaredMethod("listHotel", null);if (method.isAnnotationPresent(RedisCache.class)) {List<Hotel> redisHotelList = (List<Hotel>) redisTemplate.opsForList().range("a", 0, -1);return Optional.ofNullable(redisHotelList).filter(list -> list.size() > 0).orElseGet(() -> {List<Hotel> hotelList = hotelManager.listHotel();redisTemplate.opsForList().leftPushAll("a", hotelList);redisTemplate.expire("a", 300, TimeUnit.SECONDS);return hotelList;});} else {return hotelManager.listHotel();}}}

这是一个装饰者类，装饰了 hotelManager 这个类，通过反射获取到方法上面的注解，判断是否存在 RedisCache 这个注解，如果存在，则去redis中取得数据，否则从数据查出数据放入redis再返回。
Optional类是 java8 新增的类，有兴趣的可以了解一下。

修改 HotelController 为

@GetMapping("/listHotel")
public String listHotel() throws Exception{HotelManagerDecorate hotelManagerDecorate = new HotelManagerDecorate(hotelManager, redisTemplate);return JSON.toJSONString(hotelManagerDecorate.listHotel());
}

修改了调用方法，由原来调用hotelManager改为调用装饰者类，其实装饰者类最终还是调用了hotelManager.listHotel() 方法。

这么修改之后就可以发现，再没有修改原有代码的基础上，动态的给 hotelManager.listHotel() 方法增加了缓存功能，对方法的功能实现了增强，并且增强代码与原来的业务逻辑是分离的。装饰者只负责增强功能，业务代码根本不知道装饰者的存在，这样的做法非常易于扩展和维护，具体如何调用只是由 controller 层（高层）决定。如果将来想修改一下 RedisCache 逻辑，直接在装饰类中修改即可，根本不会影响到业务逻辑。如果将来想换一个增强的功能，直接新建一个装饰者类，修改一下 controller 调用即可。