给产品经理讲技术｜从『观察者模式』看设计模式的原则
【相关推荐】
给产品经理讲技术丨端口二三话
给产品经理讲技术｜程序员冒死揭露黑产系列之：“ARP”攻击
给产品经理讲技术丨没线，并不可怕？
给产品经理讲技术丨提需求的正确姿势是什么
给产品经理讲技术丨产品后悔药来了，讲讲热补丁技术
在撩妹技术三部曲之”设计模式“中我们抽象的了解了下设计模式，在程序员的套路：观察者模式的文章中，我们跟设计模式做了一次亲密接触。那么什么时候要用设计模式呢？今天我们通过观察者模式的例子来看看设计模式中的两个重要原则。
还是以这段代码为例：
def onUserLogout（）:
//通知朋友圈用户注销了
Moments.onUserLogout()
//通知个人相册用户注销了
Photos.onUserLogout()
//通知我的钱包用户注销了
Wallet.onUserLogout();
….
为啥我们看它不爽要改掉呢？因为它违反了一些程序设计的原则。
依赖倒转原则：就是面向接口编程，而不要面向具体实现编程。我们看到的这段代码还算整齐，至少大家都用的是onUserLogout这一个名字，如果这几个模块的开发人员思想不统一，很有可能写成
def onUserLogout（）:
//通知朋友圈用户注销了
Moments.userGoOut()
//通知个人相册用户注销了
Photos.logout()
//通知我的钱包用户注销了
Wallet.doOut();
….
虽然这里每个模块在userOut时具体的行为不一样，但是他们都有这个行为，所以就应该把这个行为抽象成接口onUserLogout，让这几个类都去实现这个接口。于是代码就变成了上面那种整齐的onUserLogout 样子。
最少知道原则：一个类对其它类知道的越少越好。显然，抽取了onUserLogout的接口还不够，作为一个被观察者，它知道的太多了，Moments，Photos，Wallet……，现在有了onUserLogout这个接口，被观察者完全可以不鸟具体的类，只需要知道接口。于是代码变成了下面的样子，可以看到被观察者除了知道onUserLogout这个接口外，其它的啥类也不知道了。
ef onUserLogout():
for observer in all_observers:
//依次遍历所有的观察者，通知它们
observer.onUserLogout()
通过这样的修改后，我们发现，被观察者中可能产生变化的观察者对象的部分被拆分出去了，留下的是可以保持不变的通知逻辑。例如，后面有个新模块MusicCenter需要知道UserLogout的事件时，只需要实现onUserLogout的接口，然后通过被观察者提供的接口把自己add to all_observers，在通知遍历时会自动遍历到它，而整个过程不再需要修改被观察者的任何代码，这个思想是符合设计模式的总原则的，即对扩展开放，对修改封闭。
当然，设计模式的原则不止这两个，在随后的设计模式讲解中，我们再来了解更多的原则，带着这些原则来看设计模式，就会知道为什么要这样设计。
欢迎添加微信公众号：给产品经理讲技术
关键字：产品经理, 设计模式, 观察者, 注销
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
