对于一个在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的时候将要怎么处理，忽略怎么去匹配操作的主体问题），将这个具体的实现交给出谋划策的人。可能这样的描述还是不容易理解，但这就是策略模式，将需要执行的事交给随时可被替换的策略者。好像刘备把谋士从徐庶换成诸葛亮，做的事还是一样 -- 打仗，可是效果完全不一样？！
或许看客和淡蓝一样，更喜欢用代码来理解。待工作之余整理……
****************************************************************************************************
****************************************************************************************************
2020.07.26
最近又开始重读设计模式，感觉之前的想法比较粗浅。其实策略模式更适用于需要动态改变行为能力的业务模型
比如说游戏，游戏角色的攻击能力，取决于武器
不同的武器赋予角色不同的攻击方式
重点在于我们不可能把这种变化硬编码到代码中，而需要能在系统运行（游戏进行）时候能够动态地切换人物的武器
而我个人理解的策略模式的一大特点便是在于此，他将行为委托给第三方
比如说我使用JPA的标准，那么我需要关心底层是用Hibernate，还是别的吗？
应该是不用的
那么理论上（实际上应该不会有这种操作，因为很多应用程序还是和具体的框架有关，没有完全面向接口），我可以在程序运行的期间，动态转化成另一种底层实现