美文网首页
设计模式第二周笔记

设计模式第二周笔记

作者: ykt146640811896 | 来源:发表于2016-09-19 21:29 被阅读0次

    Factory Method 工厂模式

    • Factory Method模式用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型,紧耦合关系(new)会导致软件的脆弱。

    • Factory Method通过面向对象的手法,将所要创建的具体对象工作延迟到子类,从而实现一种扩展(而非更改)的策略,较好地解决了这种紧耦合关系。

    • Factory Method模式解决了“单个对象”的需求变化。缺点在于要求创建方法/参数相同。

    Abstract Factory 抽象工厂

    • 如果没有应对“多系列对象构建”的需求变化,则没有必要使用Abstract Factory模式,这时候使用简单的工厂完全可以。

    • “系列对象”指的是在某一特定系列下的对象之间有相互依赖、或作用的关系。不同系列的对象之间不能相互依赖。

    • Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。

    Prototype 原型模式

    • Prototype模式同样用于隔离类对象的使用者和具体类型(易变类)之间的耦合关系。它同样要求这些“易变类”拥有“稳定的接口”。

    • Prototype模式对于“如何创建易变类的实体对象”采用“原型克隆”的方法来做,它使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象——所需工作仅仅是注册一个新类的对象(即原型),然后在任何需要的地方克隆。

    • Prototype模式中的clone方法可以利用某些框架中的序列化来实现深拷贝。

    Builder 构建器

    • Builder模式主要用于“分步骤构建一个复杂对象”。在这其中“分步骤”是一个稳定的算法,而复杂对象的各个部分则经常变化。

    • 变化点在哪里,封装哪里——Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。

    • 在Builder模式中,要注意不同语言中构造器内调用虚函数的差别。

    Facade 门面模式

    • 从客户程序的角度来看,Facade模式简化了整个组件系统的接口,对于组件内部与外部客户程序来说,达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化。

    • Facade设计模式更注重从架构的层次去看整个系统,而不是单个类的层次。Facade很多时候更是一种架构设计模式。

    • Facade设计模式并非一个集装箱,可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”,而不是一个简单的功能集合。

    Mediator 中介者

    • 将多个对象间复杂的关联关系解耦,Mediator模式将多个对象间的控制逻辑进行集中管理,变“多个对象互相关联”为“多个对象和一个中介者关联”,简化了系统的维护,抵御了可能的变化。

    • 随着控制逻辑的复杂化,Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。

    • Facade模式是解耦系统间(单向)的对象关联关系;Mediator模式是解耦系统内各个对象之间(双向)的关联关系。

    相关文章

      网友评论

          本文标题:设计模式第二周笔记

          本文链接:https://www.haomeiwen.com/subject/rnmnettx.html