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

在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#更体贴开发者，自定义事件机制还不够，还整出个委托，等等。

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

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

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

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

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