zoukankan      html  css  js  c++  java
  • 设计模式解析(N)——笔记(粗稿)

    (以后会一一补齐,最近实在木有时间)

    ·Bridge模式

    将抽象与实现解耦,是他们都可以独立变化

    Bridge模式关键特征

    意图

    将一组实现与另一组使用它们的对象分离

    问题

    一个抽象类的派生类必须使用多个实现,但不能出现类数量爆炸性增长。

    解决方案

    为所有实现定义一个接口,供抽象类的所有派生类使用

    参与者与协作者

    Abstraction为要实现的对象定义接口,Implementor为具体的实现类定义接口。Abstraction的派生类使用Implementor的派生类,却无需知道自己具体使用哪一个ConcreteImplementor.

    效果

    实现与使用实现的对象解耦,提供了可扩展性,客户对象无需操心实现问题。

    实现

    将实现封装在一个抽象类中。

    再要实现的抽象的基类中包含一个实现的句柄。注意:在Java中,你可以在实现中使用接口来代替抽象类。



    Abstract Factory模式

    为创建一组相关或相互依赖的对象提供一个接口,并且无需指定它们的具体类。

    3个关键概念步骤

    策略

    设计中的体现

    找到变化并分装之

    使用哪个驱动程序对象的选择是变化的,所以,将他封装在ResFactory类中

    优先使用对象聚集,而不是类继承

    将变化放在一个单独的对象中——ResFactory对象中,而不是拥有两种不同ApControl对象

    针对接口而不是实现设计

    ApControl知道怎样请求ResFactroy实例化驱动程序对象,但它不知道ResFactory对象如何实际实例化。


    Abstract Factory模式:关键特征

    意图

    需要为特定的客户提供对象组。

    问题

    需要实例化一组相关的对象。

    解决方案

    协调对象组的创建。提供一种方式,将如何执行对象实例化的规则从使用这些对象的客户对象提取出来。

    参与者与协作者

    AbstractFactory为如何创建对象组的每个成员定义接口。一般每个组都由独立的ConcreteFactory进行创建。

    效果

    这个模式将“使用哪些对象”的规则与“如何使用这些对象”的逻辑分离开来

    实现

    定义一个抽象类来指定创建那些对象。然后为每个组实现一个具体类。可以用表或文件完成同样的任务。

    分析矩阵


    Decorator模式

    Observer模式

    Template Method模式

    Singleton模式和Double-Checked Locking模式

    Object Pool模式

    Factory Method模式



    设计模式回顾总结


      1. 面向对象原则的总结

        1. 对象时具有明确定义的责任的事物

        2. 对象对自己负责

        3. 封装指的是任何形式的隐藏:

          1. 数据隐藏

          2. 实现隐藏

          3. 类隐藏(在抽象类或接口后)

          4. 设计隐藏

          5. 实例化隐藏

        4. 使用共性和可变性分析抽象出行为和数据中的变化

        5. 按接口设计。

        6. 将继承看成一种将变化概念化的方法,而不是创建已有对象的特殊情形。

        7. 将变化放入一个类中,并与该类中的其他变化解耦。

        8. 力求松耦合。

        9. 力求强内聚。

        10. 将使用一个对象的代码与创建该对象的代码分离。

        11. 在应用“一次且仅一次”规则时要绝对小心。

        12. 通过“按意图编程“,使用反应意图的名字,确保代码的可读性。

        13. 在编程之前就考虑代码的可测试性。

           

      2. 设计模式如何封装实现设计

        模式中描述的大多数模式都提供了隐藏具体实现的各种方式。

        隐藏实现的价值在于,模式使开发人员能够容易地添加新的实现,因为客户对象不知道当前实现的具体工作细节。

      3. 共性可变性分析与设计模式

      4. 按责任分解问题域

        共性和可变性分析可以辨识出概念视角和实现视角。如果只考虑共性和使用共性的对象,可以以另一种方式思考问题——分解责任。

        例如,在Bridge模式中,模式告诉我们将问题域看成由两个不同类型的实体(抽象和实现)组成。所以,没有必要限于只是进行面向对象的分解(也就是讲问题域分解成多个对象),也可以尝试将问题域分解成责任,如果这样更加容易的话,然后可以定义必需的对象来实现这些责任(最终还是达到了对象分解的目的)。

        将这种方法扩展一下,就是前面讲过的一条规则:设计师不应该在了解所需的所有对象对象之前操心对象的实例化。这一规则可以看成是将问题域分解成两部分:

        1. 需要哪些对象

        2. 如何实例化和管理这些对象

      5. 模式和从背景设计

      6. 模式内部的关联

      7. 实践注记

        1. 在学习模式的过程中,寻找一下因素和概念会有所帮助

          1. 这个模式隐藏了什么实现?

          2. 这个模式中有什么共性?

          3. 这个模式中对象的责任是什么?

          4. 这些对象之间有什么关系?

          5. 这个模式本身怎样成为从背景设计的微观示例?

        2. 考察模式从如下几个方面会非常有用

          1. 它封装了什么

          2. 它如何使用共性和可变性分析

          3. 它如何将问题域分解为多个责任

          4. 它如何指定对象之间的关系

          5. 它如何展示了从背景设计。

  • 相关阅读:
    java 调用Python
    RestController 能不能通过配置关闭
    java jdb
    Curator zookeeper
    「ASCII 流程图」工具——Graph Easy
    Python String Formatting Best Practices
    idea java9以及以上 出现找不到class的情况
    时间序列分析 异常分析 stl
    pip install whl
    t-SNE 层次聚类
  • 原文地址:https://www.cnblogs.com/sirocco/p/2989054.html
Copyright © 2011-2022 走看看