偶然间迸发的灵感

重构之前

模块化

模块化总是一个不错的选择，就 bison 目前的模块划分程度，我认为还是有些过于耦合，诸如在调度 Platform 的 Schedule 部分，使用了 Platfrom，Delivery， DataStore等诸多部分，并且数据的获取显得有些零散，这是我认为可以进行优化的一部分。并且在 fetch 到新 Post 之后，立刻在同一函数中进行发送，这样虽然很方便快速，但是会把 Delivery 模块也耦合进来，我认为是不应该的。这样的设计也可能是导致 Platform 类的继承关系和相关实现显得如此奇怪的原因，Platform 里的 fetch 和 parse 如同一团乱麻交织其中，我认为应该可以使用一个更为泾渭分明的设计来隔离他们，并且简化 Platform 类的设计。由于 Schedule “坏”的开头，导致 Platform，Post，Delivery都不可避免“迎合”这个最前面的设计，Bison 的重构，我认为应该就从 Schedule 开始。

Platform

目前的 Platform 类的实现可以说继承的层级显得有些过多了，这是应该的吗？或许可以有一种更好的结构来处理这种情况（这么复杂的继承一定是必要的吗）

Theme

Theme 的引入是为了实现不同样式报文的生成，但就目前的使用情况而言，Theme 的粒度是控制到整片报文，这样的粒度有时候还是显得过于粗糙了，比如我只想把 URL 替换为 二维码，把过大的动图进行压缩，这样一种只涉及到报文某个“部分”结构的变更，是 Theme 无法精确操控的，想要实现这样的效果，就需要为这样一个变更来实现一个新的 Theme，不可避免的就可能会导致“Bison-URL-Theme”， “”Bison-QRCode-Theme”这样的东西，或许我们需要把粒度进一步降低，提出一种叫“Component（组件）”的东西？ （什么WEB前端）

重构设计

进程 + 协程

基本而言对于每一个 Platform，他们需要爬取的 URL 是不同的，也就是说我们可以在 Platform 的层面上并行，而在 Platform 下属的每个账号，则保持串行(轮询)
这样可以为每一个 Platform 开启一个进程，进程内的程序是协程的（多进程？：在Python 的 GIL 还没有去掉之前可能需要这样做）
Platform 获取到的 Post，则通过 Queue 实现传回，进行进一步的处理
或许还可以考虑一下结构化并发的概念

Core

是主控程序，负责调起需要轮询的 Platform 子进程，以及除了需要开启子进程的 Platform 模块之外的模块，其在主进程中运行就可以了，
并且要负责子进程的关闭和清理

Platform

是负责爬取对应目标的模块，会按照对应的时间间隔，轮询（或者别的什么方式），获取平台数据并过滤出新数据，整理生成统一的 Post 结构，然后放入 Render 队列中等待渲染

统一的 Post 结构

Post 结构应有两部分组成: Header 和 Payload
Header 记录了平台信息，携带一些渲染时需要的平台信息和工具
Payload 则是获取到的数据，用于结果的生成
因此我们可能需要为 Platform 实现一个 parse 方法，用以生成 Post

Theme

从 Render 队列中获取一份 Post，按照 主题渲染规则 分发给对应 Theme 进行渲染，生成一份 可发送对象（Parcel），然后加入 Express 队列中等待配送
为此我们应该有一个类似 Theme.dispatch 的方法用以按Post.header来分发 Render 队列中的 Post 到相应 Theme 渲染

Parcel

Parcel 和 Post 一样，也应该分为 Header 和 Payload
Header 中记录的是可发送对象的信息，用以向对应发送目标投递 Parcel
Payload 则是 Theme.render(Post.payload) 的渲染结果

Delivery

从 Express 队列中拿到一份 Parcel，按照 Parcel.header上的 SendTarget 调用对应的适配器进行发送（一般直接交给SAA处理）