待办详细设计

目录

因为详细设计文档在内网里，所以复制了一份出来

1. 相关人员

• 设计人员：王耀

2. 需求背景

• 需按照共享平台和101教育平台的规范进行设计与开发
• 学生可以通过待办组件相关功能，获取 老师/家长 等角色布置的 打卡、通知、 作业等等待办信息，并且会通过浮窗提醒。
• 组件可复用，此后当其他项目中需要使用此组件，开发人员可以通过三种方式简单快捷地接入。
• 具备独立或者与其他组件同打包成为可用产品的能力。

3. 设计决策

3.1 组件设计

• 可复用：复用待办组件相关能力，节省开发维护成本，提供组件利用率。
• 独立提供待办列表、待办中心展示页面，使用工厂CMP方式启动，简化外部对接复杂度。
• 暴露请求接口，对外提供相关应用数据获取。
• 暴露ViewHolder相关方法，外部可直接复用Item视图。

3.2 代码设计

• 使用策略模式，将图片开源库的使用抽象成不同策略，生成工具类，开发者可以通过传入不同策略一秒钟实现切换使用不同开源库的需求。（增强代码可维护性、扩展性、易用性）
• 使用责任链模式，将点击事件的处理过程抽象成不同的拦截器（OkHttp的拦截器思想），使得复杂的点击事件处理流程得以分层，不同拦截器处理不同情况。之后若要进行新的处理条件，可以新增加新拦截器进行很方便的扩展（提升代码可读性、可维护性、扩展性）
• 使用 生产者-消费者 模型，解决多条消息的展示间隔为200ms的需求（因为积累多条消息后，用户登陆，会一次性收到n条消息推送，而每条消息接受到的间隔时间是不确定的）

4. UML图

4.1 用例图

4.1.1 接入方

4.1.2 用户

4.2 类图

4.2.1 点击事件处理类图（责任链模式）

4.2.2 图片开源库使用类图（策略模式）

4.3 流程图

4.3.1 点击事件处理流程图

4.4 时序图

4.4.1 浮窗时序图

5. 设计理由

5.1 使用策略模式理由

• 实际上，项目中所用到的所有开源库，都用上策略模式封装了一层。
• 相比于没有封装一层而直接在项目中使用，我的工具类的好处是在替换成其他开源库的时候极其简单快捷，而不用找到项目中每个使用到的地方都进行替换，那样的工作是极其费时且没有意义的。
• 相比于只是封装一层而没有用策略模式，我的工具类的好处在于可以使多个开源库策略并存，方便替换，也满足了开闭原则，对修改关闭，对扩展开放。只是封装一层的话，要替换开源库就要对代码进行修改。

5.2 使用责任链模式理由

• 点击事件的处理相当复杂，而且后续很可能还会进行扩展。
• 如果没有使用责任链模式，那么处理流程代码量多而杂，没有明确的分层，光是各种处理方法的跳转都能让人绕晕，更别说还有各种判断等，可读性极差。
• 使用责任链模式，将每一层处理都抽象成一个拦截器，后续如果要有新的处理条件，可以在满足开闭原则的前提下很轻松的进行扩展。
• 分层处理，分别处理href、mq、biz、webUrl的情况，每一层逻辑处理、解析等，都放在相应的拦截器中，非常清晰，可读性增强。

5.3 使用生产者-消费者模型 理由

• 策划有个需求，是多个消息的情况下，要在固定间隔时间（200ms）进行切换。而消息的推送和接收间隔和时机是不确定的;再者待办消息有可能非常多，为了不占用过多内存，则使用阻塞队列限制最大存储消息数量。
• 因此使用大小为500的阻塞队列对消息进行了缓存，在一个Service中消费消息。
• 假设每条消息平均400个英文，200个中文，则占用1000字节约等于1kb。最大500条，则最大占用0.5m。