设计一个小框架考虑的东西真不少,每一样都不easy:
1、既要解决当前技术的不足;
2、又要方便他人使用(基本的目的)。
3、同一时候又要设计得优雅。easy扩展。
sophia一開始设计用来支持智能回复(文本能够带參数的回复)。后来又支持菜单。并统一了菜单和文本命令的处理逻辑。
再后来看到微信client的交互元素太少,又支持html页面操作和微信client的会话(即页面操作能够知道是哪个微信号操作的)
对于怎样维系两个不同类型消息(命令)之间的关系?对sophia来说有点吃力。
即,前面是一个文本(命令)。后面是一个其它类型的消息。
比方,某街道办让我们开发一个居民登记公众平台,主要流程例如以下:
1、订阅者输入:登记
2、公众平台提示:请输入姓名:
3、订阅者输入:张三
4、公众平台提示:输入身份证号码:
5、订阅者输入:xxxxxxxxxxxxxxxxxx
6、公众平台提示:请上传免冠相片:
7、订阅者上传相片。
8、公众平台提示:登记成功。
订阅者经过多次文本输入和图片上传后,公众号怎样保证前面的文本信息和最后的图片是同一个人的?
假设看了sophia的源码和设计后(參阅我前面的文章)会发现sophia无法做到?由于我一開始就把sophia设计为处理文本消息的框架。
如今,假设要解决问题,那么:
1、首先把全部的消息(文本、视频、语音、图片、地理位置等,或者说每种交互)都觉得是一种命令。让框架都有机会处理;
2、其次要改动会话管理逻辑。
插播:
消息的多样性:指同一种类型的消息。能够依据内容来解析出不同的命令,比方文本消息具有这个特性。
像图片无法解析出不同的内容,所以没有多样性(用图像识别、语音识别技术除外)。
这个概念会影响我们的设计。
1、因为文本消息具有多样性,其相应的命令类就能够有不同的子类型。而非文本消息,仅仅能有一个命令类,合适吗?
2、假设把非文本消息作为文本消息的特殊类型,又怎样?
初步考虑扩展将文本命令类添加一个标记(支持后继是非文本消息继续处理),假设公众平台收到非文本命令时候要检查一下session中是否存在文本命令对象是否支持后继非文本消息处理,然后调用此对象继续处理。
你有更好的方案吗?欢迎讨论。