给产品经理讲技术|从『观察者模式』看设计模式的原则

产品经理

【相关推荐】

给产品经理讲技术丨端口二三话

给产品经理讲技术|程序员冒死揭露黑产系列之:“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,在通知遍历时会自动遍历到它,而整个过程不再需要修改被观察者的任何代码,这个思想是符合设计模式的总原则的,即对扩展开放,对修改封闭。

当然,设计模式的原则不止这两个,在随后的设计模式讲解中,我们再来了解更多的原则,带着这些原则来看设计模式,就会知道为什么要这样设计。

欢迎添加微信公众号:给产品经理讲技术

产品经理

关键字:产品经理, 设计模式, 观察者, 注销

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部