WM有约II(六):分级限制
如何界定访问级别?
首先,发送方要么在联系人里,要么不在,如果不在,那么他/她的访问级别就是Stranger,如果在,我们还要看看他/她是否在白名单或者黑名单里,如果也在,那么他/她的访问级别就是Whitelist或者Blacklist,否则就是Contact。就实现方式而言,我们应该优先考虑检查白名单和黑名单,因为从集合的角度来看,它们均是联系人的子集,如果发送方在任一名单里,我们就可以立即返回他/她的访问级别,而不必遍历所有联系人,于是,我们可以这样获取发送方的访问级别:
代码 4
那么,查询操作的访问级别又如何获取呢?我们知道,应用程序(目前)只支持三种查询操作,每种操作所需的最低访问级别如下表所示:
查询操作 |
所需的最低访问级别 |
PingStatus |
Contact |
PingSchedule |
Whitelist |
SignUp |
Stranger* |
*SignUp只针对陌生人开放。
不难看出,上表包含了查询操作和访问级别的映射关系,于是我们可以这样获取查询操作所需的最低访问级别:
代码 5
- A:且慢!为何要用switch?
- B:别激动,就目前而言,switch已经可以满足我们的需求了……
- A:目前?难道你不打算为将来做些什么吗?
- B:你是活在将来的吗?如果不是,你怎么知道将来会变成怎样?
不知道从什么时候开始,我也把思维的战线拉长了,比如说,当我写下上面那个表格时,我的脑子里就出现了代码5,接着,我直接在脑子里对它进行重构,想着设计模式,思考着如果不修改ISmsProcessor接口,要如何设计才可以使各个查询操作及其访问级别的关连变得更自然平滑,如果要让用户可以配置每个查询操作的访问等级,又要添加哪些类型,而这些配置信息又该以什么样的形式存储,如何管理等等。人们似乎对预测未来乐此不疲,也发明了各式各样的预测方法,或许,人们讨厌在毫无准备的状态下迎接未来的到来,但未来在到来之前只不过是一个虚幻,而且不稳定,如果我们过度依赖对未来的预测,那将会束缚现在,也会抹杀其它可能的未来……
回到我们的节目,假设我们继续使用代码5的GetSmsProcessorAccessLevel方法,我们如何才能判断发送方能否执行某个查询操作呢?很简单,我们可以通过GetSenderAccessLevel方法获取发送方的访问级别,接着判断这个级别是否在某个查询操作所需的最低访问级别之上(或者两者的访问级别相同),如果是,则可以执行该查询操作,于是,我们可以把SmsProcessorBase.IsAuthorized方法改成这样:
代码 6
好了,又到测试的时候了,沿用上面的测试结果,下表列出了本次测试所用的4个手机号码及其访问级别:
姓名 |
手机号码 |
访问级别 |
Jay Chou |
15834561144 |
Whitelist |
Eason Chan |
15933449394 |
Contact |
Leehom Wang |
13813572468 |
Stranger |
Allen Lee |
13733449394 |
Blacklist |
我们将会通过Cellular Emulator分别用这4个手机号码发送如下两个查询短信息:
- {Trombone:PingStatus}
- {Trombone:PingSchedule(2/15/2009 3:30 PM)}
图 10
从上图可以看到,只有3个自动回复,这是预期的结果,再来看看模拟器上的应用程序:
从上图可以看到,其它发出的查询短信息都被成功忽略了。