观察者模式与依赖倒转原则

观察者模式是对依赖倒转原则很好的应用。单纯去看依赖倒转原则,我并不明白。什么“抽象不能依赖细节,细节要依赖抽象的”。看完观察者模式后,我觉得这一原则还是很经典,很实用的。

下面就利用《大话设计模式》中,举的前台和看股票的观察者模式的例子,来说一下我对这一原则的理解。

没有用观察者模式时

具体的通知者(Secretary)和具体的观察者(StockObserver)二者是相互依赖的。

Secretary类中的Attach(StockObserver observer)方法需要知道StockObserver,而StockObserver也需要知道Secretary的状态SecretaryAction。

从通知者角度看(通知者依赖观察者),那么它本身是高层模块,具体的观察者是低层模块,高层模块依赖低层模块。

从观察者角度看(观察者依赖通知者),那么它本身是高层模块,具体的通知者是低层模块,高层模块依赖低层模块。

这样的坏处是如果具体的观察者发生变化,那么我们需要修改Attach方法,如果通知者发生变化,我们需要修改观察者所依赖的通知者的状态。

用了观察者模式后:

具体的观察者或者是通知者都依赖于更高层次的抽象类。(Observer是具体观察者的抽象,Subject是具体通知者的抽象)即“高层模块不应该依赖低层模块,两个都应该依赖抽象”。

这样的好处是,具体观察者和通知者想怎么变就怎么变,通过增加相应的子类即可,而不是修改现有的类。而他们各自的抽象类不会变,从这里也能看出“变是永远不变的”。

观察者模式与依赖倒转原则

时间: 2024-10-09 07:51:25

观察者模式与依赖倒转原则的相关文章

大话设计模式之依赖倒转原则

依赖倒转原则: 定义: 在大话中最重要的两句话是:抽象不应该依赖与细节,细节应该依赖于抽象.还有一句是:针对接口编程,不要对实现编程. 问题: 类A直接依赖类B.假如要将类A改为依赖C.则必须通过须要改动类A的代码来达成.但假设,类A是高级模块,负责业务逻辑:类B和类C是低层模块.负责主要的源自操作.这样改变A会给程序带来不必要的风险. 解决方式: 将类A改动为依赖接口I,类B和类C各自实现接口I,类A通过接口I来与类B和C发生纤细,则会大大减少改动A的几率. 基本思想: 用抽象构建框架.用事先

第五话-依赖倒转原则

 哎,真是纠结.2011年买的笔记本,2G内存,320G硬盘,i3处理器.现在用着好卡呀.呜呜.怎么办?买个新的吧太贵了,5K呀.还好,可以买个4G内存,再买个1T硬盘.加起来顶多1K哦,同样感受飞一般的感觉.太好了. 可是,我2012年买的手机好卡呀.配置好低呀.呜呜,iphone6都出了.4G时代都流行了,NFC功能爽歪歪.哎,只好换了! 为什么电脑可以换零件,手机就不能呢?这是因为,Computer在设计时非常注重面向对象的思想哦.这就是面向对象的好处. 那么什么才是真正的面向对象呢?

《大话设计模式》:依赖倒转原则

依赖倒转原则 1,高层模块不应该依赖低层模块,两个都应该依赖抽象. 2,抽象不应该依赖细节,细节应该依赖抽象.针对接口编程,不应该针对实现编程. 里氏代换原则 一个软件实体如果使用的是一个父类的话,那么一定适用于其子类,而且察觉不出父类对象和子类对象的区别.也就是说,在软件里面,把父类都替换成它的子类,程序的行为没有变化. 子类型必须能够替换掉他们的父类型. 只有当子类可以替换掉父类,软件单位的功能不受影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为. 由于子类型的可替换性才使

设计模式--依赖倒转原则

依赖倒转原则又称依赖倒置原则: 抽象不应该依赖细节,细节应该依赖于抽象.说白了,就是针对接口编程,不要针对实现编程. 依赖倒置原则包括三层含义: 1)高层模块不应该依赖低层模块,两者都应该依赖其抽象: 2)抽象不应该依赖细节; 3)细节应该依赖抽象. 看了上面的解释相信大家会和我一样会有一些疑问在脑海里,以下来具体说一说吧: 1)为什么要针对接口编程,而不是针对实现编程呢? 非常easy的一个样例.我们如今使用的电脑有各式的品牌.联想.神舟.戴尔等等, 电脑须要用到鼠标,键盘:如果鼠标.键盘是针

【转载】依赖倒转原则

3.1 依赖倒置原则的定义 依赖倒置原则(Dependence Inversion Principle,简称DIP)这个名字看着有点别扭,"依赖"还"倒置",这到底是什么意思?依赖倒置原则的原始定义是:High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon

设计模式原则(3)--Dependency Inversion Principle(DIP)--依赖倒转原则

1.定义: 高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 抽象不应该依赖于细节,细节应当依赖于抽象.换言之,要针对接口编程,而不是针对实现编程. 2.使用场景: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险.即将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C

设计模式之刘伟老师文章学习记录-------------依赖倒转原则

如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要实现机制之一,它是系统抽象化的具体实现.依赖倒转原则是Robert C. Martin在1996年为"C++Reporter"所写的专栏Engineering Notebook的第三篇,后来加入到他在2002年出版的经典著作"Agile Software Development, Principles, Patterns, and Practices"一书中.依赖倒转原则定义如下: 依赖倒

大话设计模式---依赖倒转原则

依赖倒转原则 高层模块不应该依赖低层模块.两个都应该依赖抽象. 抽象不应该依赖细节.细节应该依赖抽象. 里氏代换原则:子类型必须能够替换掉它们的父类型.

设计模式之依赖倒转原则(DIP)

1.概念 DIP:Dependency Inversion Principle 抽象不应当依赖于细节,细节应当依赖于抽象(说通俗点也就是要针对接口编程,不要针对实现编程:或者要依赖于抽象,不要依赖于具体). 2.为何叫"依赖倒转"? 传统的过程性系统的设计办法倾向于使高层次的模块依赖于低层次的模块:抽象层次依赖于具体层次.倒转原则则是把这个错误的依赖关系倒过来. 3.如何做到依赖倒转? 以抽象方式耦合是依赖倒转原则的关键.由于一个抽象耦合关系总要涉及到具体类从抽象类继承,并且需要保证在