对于一个在java领域基础还还没有那么扎实的人来说，或许谈框架和设计模式对我，都显得有些好高骛远。
但或许源于自身在工作中学习的一些坏习惯吧！我也不怎么过多地再去看算法与数据结构这样晦涩的东西。对于设计模式也仅仅是认为 -- 一个程序员所必须掌握的技能之一，对吧？我的认知还是如此浅薄，至少在此。
前一段时间，淡蓝所负责的短信接口模块与同事一起配合完成了一块所谓的“事件机制”，实际上就是通过短信的上下行做一个通讯功能，或者说跟微信公众号也差不多吧。在现实中比较常见的应用如手机付款，发送短信给你“xx先生您好，你在厦门xx分店消费的￥550元账单已发送到你的邮箱，确认请回复’Y‘”。当然上述只是我的一个设想，并非真实的场景。
实际的业务场景
1、商城系统推送 一封 需要回执的短信（回执：即回复短信，’TD‘（退订）……） -- 下行短信
2、收到短信后回复对应格式的内容 -- 上行短信
3、商城从第三方短信中间商拉取或被推送（观察者模式），获取到消费者回复的内容。根据格式判断应该执行的操作:如重置密码
实际的技术场景
1、系统a通过短信服务商c发送一条短信给个人b
2、短信服务商c推送下行短信给个人b
3、个人b收到短信运营商推送过来的短信，并根据提示回复
4、短信服务商c获取到个人b发过来的上行消息，记录起来
5、短信服务商c根据实际的业务支持，等待系统a主动拉取上行消息或主动推送上行消息
6、系统a获取上行消息，并根据其内容进行业务流操作。
ok，原谅我的表述能力，或许已经丢掉策略模式，但我们还是得回过头来看看究竟为什么要用策略模式，用在哪里？
实际的需求是这样的，我们必须要对第三方推送的数据做一定的逻辑处理，但我们无法确定消息的推送来源。如短信、微信、邮箱等。所以我们必须坚持“面向接口编程，而非面向实现编程”的设计原则。而且我们不知道发送的将是什么内容，将要做什么操作。所以预留一个一个的接口（如回复y的时候将要怎么处理，忽略怎么去匹配操作的主体问题），将这个具体的实现交给出谋划策的人。可能这样的描述还是不容易理解，但这就是策略模式，将需要执行的事交给随时可被替换的策略者。好像刘备把谋士从徐庶换成诸葛亮，做的事还是一样 -- 打仗，可是效果完全不一样？！
或许看客和淡蓝一样，更喜欢用代码来理解。待工作之余整理……