• 设计模式学习


    参考出处:https://www.cnblogs.com/zhili/p/DesignPatternSummery.html

    类设计的几个原则

    单一职责原则、开放封闭原则、里氏代替原则、依赖倒置原则、接口隔离原则、合成复用原则和迪米特法则。

    1.单一职责原则

          就一个类而言,应该只有一个引起它变化的原因。如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会影响到其他的职责,另外,把多个职责耦合在一起,也会影响复用性。

    2.开闭原则

      开闭原则即OCP(Open-Closed Principle缩写)原则,该原则强调的是:一个软件实体(指的类、函数、模块等)应该对扩展开放,对修改关闭。即每次发生变化时,要通过添加新的代码来增强现有类型的行为,而不是修改原有的代码。

      符合开闭原则的最好方式是提供一个固有的接口,然后让所有可能发生变化的类实现该接口,让固定的接口与相关对象进行交互。

    3.里氏代替原则

    指的是子类必须替换掉它们的父类型 。也就是说,在软件开发过程中,子类替换父类后,程序的行为是一样的。只有当子类替换掉父类后,此时软件的功能不受影响时,父类才能真正地被复用,而子类也可以在父类的基础上添加新的行为。为了就来看看违反了LSP原则的例子,具体代码如下所示:

    4.依赖倒置原则

    原则指的是抽象不应该依赖于细节,细节应该依赖于抽象,也就是提出的 “面向接口编程,而不是面向实现编程”。这样可以降低客户与具体实现的耦合。

    5.接口隔离原则

    接口隔离原则(Interface Segregation Principle, ISP)指的是使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担过多的职责,而应把每个职责分离到多个专门的接口中,进行接口分离。过于臃肿的接口是对接口的一种污染。

    6.就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分。新对象通过向这些对象的委派达到复用已用功能的目的。简单地说,就是要尽量使用合成/聚合,尽量不要使用继承。

    7.迪米特法则

    指的是一个对象应当对其他对象有尽可能少的了解。也就是说,一个模块或对象应尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立,这样当一个模块修改时,影响的模块就会越少,扩展起来更加容易。

    设计模式的类型区分

     1.创建型模式

     创建型模式就是用来创建对象的模式,抽象了实例化的过程。所有的创建型模式都有两个共同点。第一,它们都将系统使用哪些具体类的信息封装起来;第二,它们隐藏了这些类的实例是如何被创建和组织的。创建型模式包括单例模式、工厂方法模式、抽象工厂模式、建造者模式和原型模式。

    • 单例模式:解决的是实例化对象的个数的问题,比如抽象工厂中的工厂、对象池等,除了Singleton之外,其他创建型模式解决的都是 new 所带来的耦合关系。
    • 抽象工厂:创建一系列相互依赖对象,并能在运行时改变系列。
    • 工厂方法:创建单个对象,在Abstract Factory有使用到。
    • 原型模式:通过拷贝原型来创建新的对象。

    2.结构型模式

    结构型模式,顾名思义讨论的是类和对象的结构 ,主要用来处理类或对象的组合。它包括两种类型,一是类结构型模式,指的是采用继承机制来组合接口或实现;二是对象结构型模式,指的是通过组合对象的方式来实现新的功能。它包括适配器模式、桥接模式、装饰者模式、组合模式、外观模式、享元模式和代理模式。

    • 适配器模式注重转换接口,将不吻合的接口适配对接 
    • 桥接模式注重分离接口与其实现,支持多维度变化 
    • 组合模式注重统一接口,将“一对多”的关系转化为“一对一”的关系 
    • 装饰者模式注重稳定接口,在此前提下为对象扩展功能 
    • 外观模式注重简化接口,简化组件系统与外部客户程序的依赖关系 
    • 享元模式注重保留接口,在内部使用共享技术对对象存储进行优化 
    • 代理模式注重假借接口,增加间接层来实现灵活控制

    3.行为型模式

    行为型模式是对在不同对象之间划分责任和算法的抽象化。行为模式不仅仅关于类和对象,还关于它们之间的相互作用。行为型模式又分为类的行为模式和对象的行为模式两种。

    • 类的行为模式——使用继承关系在几个类之间分配行为。
    • 对象的行为模式——使用对象聚合的方式来分配行为。

      行为型模式包括11种模式:模板方法模式、命令模式、迭代器模式、观察者模式、中介者模式、状态模式、策略模式、责任链模式、访问者模式、解释器模式和备忘录模式。

    • 模板方法模式:封装算法结构,定义算法骨架,支持算法子步骤变化。
    • 命令模式:注重将请求封装为对象,支持请求的变化,通过将一组行为抽象为对象,实现行为请求者和行为实现者之间的解耦。
    • 迭代器模式:注重封装特定领域变化,支持集合的变化,屏蔽集合对象内部复杂结构,提供客户程序对它的透明遍历。
    • 观察者模式:注重封装对象通知,支持通信对象的变化,实现对象状态改变,通知依赖它的对象并更新。
    • 中介者模式:注重封装对象间的交互,通过封装一系列对象之间的复杂交互,使他们不需要显式相互引用,实现解耦。
    • 状态模式:注重封装与状态相关的行为,支持状态的变化,通过封装对象状态,从而在其内部状态改变时改变它的行为。
    • 策略模式:注重封装算法,支持算法的变化,通过封装一系列算法,从而可以随时独立于客户替换算法。
    • 责任链模式:注重封装对象责任,支持责任的变化,通过动态构建职责链,实现事务处理。
    • 访问者模式:注重封装对象操作变化,支持在运行时为类结构添加新的操作,在类层次结构中,在不改变各类的前提下定义作用于这些类实例的新的操作。
    • 备忘录模式:注重封装对象状态变化,支持状态保存、恢复。
    • 解释器模式:注重封装特定领域变化,支持领域问题的频繁变化,将特定领域的问题表达为某种语法规则下的句子,然后构建一个解释器来解释这样的句子,从而达到解决问题的目的。

    23种设计模式,其实前辈们总结出来解决问题的方式,它们追求的宗旨还是保证系统的低耦合高内聚,指导它们的原则无非就是封装变化,责任单一,面向接口编程等设计原则

  • 相关阅读:
    根据指定的编码格式返回请求的参数集合
    【C++ 学习笔记】 size_t 和 int
    C++ 编译错误
    【Flex】 加载Gif文件
    【C++ 学习笔记】:STLmap
    【C++ 学习笔记】:MFC(细节部分)
    小卡的土豆园开园了~
    [论文笔记] A novel reduction approach to analyzing QoS of workflow processes (Concurrency and Computation: Practice and Experience, 2009)
    [论文收集] WWW2008 相关或感兴趣的论文
    [论文泛读] Accurate and efficient stochastic reliability analysis of composite services using their compact Markov reward model representations (SCC, 2007)
  • 原文地址:https://www.cnblogs.com/muxueyuan/p/11154567.html
Copyright © 2020-2023  润新知