欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

略淡 工厂方法模式 与 观察者模式 工厂方法模式观察者模式 

程序员文章站 2022-05-31 08:22:47
...

在http://www.iteye.com/topic/1119458?page=11 中,自已稍微整理了一下这两个模式,觉得有意义,收在了本博客中。



不是大师,资质愚钝的一个人罢了。既然叫阵了,就简单抛砖引玉吧。

简单说说 工厂方法模式。 设计人员经常面对 一个具体功能的类,这个类完成具体的功能(比加 是自定义的组件有某种功能的panel),但这个类的实例生成有可能很复杂,效率还不确定,有可能需要调用配置文件,而配置文件种类格式要很多,或者外观有很多的变化。 此时,如果设计人员意识到这种情况了,注意,这里有需求变化了,就应该考虑用模式了。分析,当这个类的具体功能在这开发中是不变的,仅生成实例的具体方式要变化,怎么办?就在这里封装变化点。从生成实例给分开,把生成实例这个功能 用一个类给封装起来 ,当要生成实例时,就调用这个封装起来的类的某个方法,生成实例即可。这样当需要改变这个类的生成方式时,仅需要在生成方法所在的类中去更改,并且不影响其他地方对该类的使用。但性能或外观,或配置方式灵活性却大大的提高了。至于在生成方法中,是否还有需求变化点,不在工厂方法模式讨论之中。略去。

这就是在需求阶段设计:封装变化点。 而不是写好了整个程序,发现了有大量的重复,然后重构。而是要在软件需求功能设计时,就可以考虑进去了。

再简单说说,观察者模式,各种书中的的定义都有了,不谈实义了,同理也不谈什么UML对象与代码。但对设计人员来说,就一句最适用“一处变化,其他各处都要变化”。什么意思? 就是类A 某个属性发生变化,或某个方法执行时,其他多个类B(多个,都统称一个,即考虑一处跟随变化)要跟着相应变化。 在这种场合,就要考虑使用观察者模式了。  举个简单例子:一个设计人员在 设计一个panel,用A称呼,这个panel的位置、大小也要跟着变化,而另一个panel,用B称呼,要即时展现出A的位置大小消息,最烦人的是, 这个Panel有多种,还多个地方出现。如果是设计人员,应该意到,这里有变化了,需要把A的变化,与B的跟随变化分割并封装起来。 当然了,用观察者模式,或变形了的观者模式(严重申明,这种场合的这个模式,与GOF的观察模式有点出入)。 如何实现?最简单思想是,A调用B中方法,即A中发生变化了,直接调用B中方法。为了适应更多场合:通常引用中间类,这里称C。 使用时,A 发生变化,调用C的一个方法(称为通知方法),C又调用B的一个方法(接收方法)。当然了,使用前,C要把自已的实例 放入到A中保存起来,A在事前的状态发生变化时,要调用保存当里面的C实例的通知方法; 当然了,使用前,B要把自已的实例,放入到C实例中保存起来,事前C实例的通知方法,要调用B的接收方法。 如果仅当到此,这是一个变了样的观察者模式。

再多啰嗦几句观察者模式,这个使用的地方比较多,为了方便 ,java中出现了JavaBean的关联属性,而C#更体贴开发者,自定义事件机制还不够,还整出个委托,等等。

如果要按作者的书中所说的去搞,当发现了大量的重复代码了,再想通过重构,从而再寻找设计模式,不知到要历练到猴年马月。

在需求阶段,完成较详细的需求设计时,就应该 意识到如何使用设计模式。而要在需求阶段意识到,实践证明有效的办法之一就是 :封装变化点。 这是设计模式的灵魂。故,设计模式理解深入的作者都会把 封装变化点这一方法,列为设计模式基本原则之一。至于面向接口,而不是面向类。这一原则,有些人领悟能力低,不说了。

本人仅仅是粗浅理解,还没完全应用到复杂项目中。孙武,在年青时就写了孙子兵法一书,但却用尽一生去验证,实践。我就不再高淡阔论了,还是务实的到实践项目构思、设计、实现去验证自已的理解与领悟吧。

如果有对设计模式感兴趣的,可以私下讨论交流,或另开贴讨论。但不保证,我会随时解答,交流的,我还有许多东西要去做,要去验证。

悟性决定境界,而不是看英文书籍多与少,也不是代码重构了多长时间,也不是阅读别人的源代码,更不是忽悠就能达到。