给产品经理讲技术|从『观察者模式』看设计模式的原则
【相关推荐】
给产品经理讲技术丨端口二三话
给产品经理讲技术|程序员冒死揭露黑产系列之:“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,在通知遍历时会自动遍历到它,而整个过程不再需要修改被观察者的任何代码,这个思想是符合设计模式的总原则的,即对扩展开放,对修改封闭。
当然,设计模式的原则不止这两个,在随后的设计模式讲解中,我们再来了解更多的原则,带着这些原则来看设计模式,就会知道为什么要这样设计。
欢迎添加微信公众号:给产品经理讲技术
关键字:产品经理, 设计模式, 观察者, 注销
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!