先上图片。
根据图片来说一下其中的想法。（注：图中的service指的是业务层）
1. 真实的缓存对象存放在Cache类中，被protected修饰，CacheProxy类实际不储存任何缓存对象，其与Cache类同包，并为外部提供public方法访问Cache。
a.Protected修饰保证只有CacheProxy可以访问Cache类。在协同开发中就不用担心有人绕过了你的设计直接访问Cache。
b.CacheProxy可以提供更加丰富的方法，比如缓存中是个List对象，根据需要Facade可以提供将其变为map并返回的方法。或者为了保证原缓存对象不被修改，取对象的时候深拷贝一个对象并返回。
2. CacheManagerService负责统一更新缓存的逻辑。
a. 更新缓存的逻辑，涉及到怎么取需要的数据，怎么存。怎么取数据这一步主要是业务逻辑，不应该在CacheManageService中实现，应该定义一个接口，由另外一个类去实现。CacheManageService只要负责调用接口（图中的ExternalDataService/FileDataService/DbDataService）。
这样做一个是业务相关代码可以重用，再一个即使这部分业务逻辑变了CacheManageService也不受影响（业务逻辑很可能变），另外一个其实也很重要就是使得CacheManageService代码易读。
b. CacheManageService统一负责更新，使得更新这一块逻辑容易修改。比如想加个锁呀，换个锁呀，感觉都不难。
3. MonitorCenter这一块负责监控缓存更新条件，并且触发缓存更新（调用CacheManagerService更新缓存）。这里我认为观察者模式是很适合的，我将其分为三块:MonitorCenter类，Monitor(被观察者)，Observer(观察者)。
a. MonitorCenter类负责这个监控模块的初始化，统一注册观察者们到Monitor(被观察者)中。程序启动的时候调用一下MonitorCenter的初始化方法就行拉（图中的register方法）。
b. Monitor负责监控相关消息，比如已经到每天的凌晨两点，收到新的消息，文件有更新。然后通知Observer。
c. Observer负责收到通知的时候，判断是否要更新，然后触发CacheManageService的相关更新方法。
判断是否要更新这个逻辑是要放在Observer中的，比如图中MessageAObserver和MessageBObserver自己判断是不是消息A和消息B。试想一下如果放到MessageMonitor中那他需要判断这个消息是什么，还要从观察者列表中找到MessageAObserver，并且保证消息不能发给MessageBObserver。好吧，这想想就够了，别去做这种事。
4. start，在程序启动的时候只需要调用两个方法就能使得这个模块正常运行。一个是CacheManagerService的init方法初始化缓存。一个是MonitorCenter的register方法让其在合适的时间触发缓存的更新。
