后台消息推送框架设计

前言

　　最开始自己公司的后台推送系统只能是用户在线时推送，推送消息也不会保存，若用户离线，那么这条推送消息就再也无法获取。更让人头疼的是：推送的内容和推送系统是耦合在一起的，这样往往在改一处代码的同时，会出现意想不到的bug。着就更加坚定了自己要把推送代码重构的决心了。下面就是自己的整个设计过程和期间遇到的问题，写出来和大家分享一下，望大家多多指教。

设计过程

　　最开始设计的时候是把数据的存储，修改和消息的推送放到一个类中pushmanager中，各种消息都糅合到一个message中，从后台拉取消息单独提出来pullManager，如图1：
　　
　　
　　上面的设计有如下弊端：
　　1、Message来表示各种类型的消息，而它又与数据库表直接关系，这样Message要把各种消息类型的不同点都包含进来，这样，添加一个消息类型，就要在数据库中添加字段来表示它与其他类型不同点。不符合开闭原则，维护性极差。
　　2、消息存储和推送的耦合性太强了。

　　针对上面问题，对其做了进一步的优化（如下图）：
　　1、用MessageTypeBase这个抽象类来将消息的共同行为和属性抽象出来，各种不同类型的消息继承这个抽象类，然后再针对不同类型的消息添加不同的行为和属性
　　2、将消息存储和推送两个分开，messageManager负责消息的增删改查（拉取消息的行为也放入其中），它对外提供服务，Pu