消息中心的重构
话说这几天，王小二经过C哥的精心指导，初步领悟了设计模式的魅力。
于是小二又着手对消息中心进行了设计与重构，看，下面就是小二画的UML类图。
小二自忖：嗯...看着还不错嘛，不管是发送短信还是发送邮件，因为两者都继承自抽象类Message，所以可以方便的利用面向对象的多态性，这样就进一步实现了针对接口编程，perfect!
（btw:不了解多态的童鞋，请戳：OOP三大特性:封装、继承、多态 补补课^_^）
消息中心的新成员
新的一天又开始了，小二感觉每天都在进步，这种感觉特别充实，或许，码农的快乐就是这么真实简单。
北京的地铁依旧人潮涌动，硬着头皮终于挤上了地铁。9:20，小二到了公司。
“小二，你手头还有活没？”老大走过来说道。
“之前的需求刚刚完事，没什么事情了。”
“好，消息中心现在支持发送短信与邮件是吧？”
“是的，支持的。”
“嗯，不错。你知道咱们公司微信会员特别多，所以发送微信这块，也要接到消息中心来。你觉得可以实现吗？”
“嗯...可以实现，现在消息中心的结构很清晰，2天就能搞定！”
“好，不错，你开始做这块吧!”
"好的，没问题。"
小二心想：“微信接入消息中心还不简单嘛，我已经对消息中心重构了，接入一个新成员还不是分分钟搞定的事儿！”
善用github
码农界流行一句话：“不要重复造轮子”。
小二对这句话深有体会，最近还参与了github上几个开源项目呢！
开工之前，小二灵机一动："发送微信，肯定是个通用的功能，github上应该有开源的项目吧？我去找找！"
不搜不知道，一搜吓一跳，还真不少呢。
小二在github上千挑万选，终于选定了一个项目。
为了更清晰的将这个项目接入消息中心，小二又针对这个项目画了一个简单的类图。
画完类图，小二仔细分析了一下：咦？github上这个WechatMessage类中的方法，与现有消息中心的接口不一样啊。既然不一样，那么就无法继承自抽象类Message。那么，就无法实现多态了，也就不能针对接口编程了。哎，好不容易找了一个开源项目，最后空欢喜一场。难道真的要自己重写一个WechatMessage类吗？￣へ￣
这时，小二又想到了万能的C哥。
小二想：“C哥或许有办法，再去请教下C哥吧！”
Adapter模式解千愁
小二找到C哥，大体描述了下自己的问题。
“小二啊，面对新需求，你首先能想到去github上找有没有开源的实现，这种方法是值得鼓励的，赞一个！”
“哈哈，谢谢C哥，开源就需要有人参与有人用嘛！”
“嗯嗯。你这个问题，可以用设计模式中的Adapter模式去解决。”
“还有Adapter模式？望C哥指点一二。”
“我给你画个类图你就明白了。”
"哦哦，我明白了，中间加一个适配器，就适配了不兼容的类"。
“对的，就是这个意思。”
“你有没有看过安卓苹果转接头，那就是一个适配器。”
“嗯嗯，见过，C哥说的太形象了，确实是！”
Adapter模式与Facade模式的区别
“C哥，前几天你给我讲的Facade模式，是对接口进行了包装。Adapter模式，也是对接口进行了包装适配。这两个看似区别不大啊？”
“区别还是有的，要不然也不会有两个设计模式的名字。”
“嗯嗯，他俩有什么区别呢？”
“Facade模式的目的，是为了提供一个简单易用的接口给用户。而Adapter模式的目的，是为了适配某个类，从而保持对象的多态行为。”
“哦，这样啊！”
“是的，最大的不同，就是他们俩的目的不同。Adapter模式最常用的场景就是用来保持对象的多态行为。”
“嗯嗯，我明白了，多谢C哥”。
“类图都给你画出来了，代码就不要我给你写了吧？”
“哈哈，不用不用，我自己来写就行了，有了类图，分分钟搞定！”
“哈哈，小二加油，有什么不会的再问我。”
优雅的使用别人的轮子
拿着C哥画好的类图，小二很快进行了适配，优雅的使用了github上的项目。
3个小时过后，小二成功实现了消息中心接入发送微信消息的功能。
小二心想：“这适配器模式真管用，大大解放了我们一线码农的生产力，以后可以优雅的使用别人的轮子了，✌️”！
设计模式等系列文章，首发于公众号“聊聊代码”，关注公号，让我们一起聊聊“左手代码右手诗”的事儿。
扫一扫
742
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
