python设计模式(一)--概述

一、概述

1.1 设计模式

  • 定义:面向对象(object)编程,面对某一特定问题 进行的 针对 类或对象组合的创建、组织、通信解决方案

    解决方案:并不描述一个特定而具体的设计或实现,而是提供设计问题的抽象描述 和 怎样用一个具有一般意义的元素组合(类或对象组合)来解决这个问题


  • 实质:方案描述了设计的组成成分及成分间的相互关系职责协作方式
  • 应用领域:寻找变化点,然后在变化点处应用设计模式,从而更优应对需求的变化
  • 面向对象程序:由对象组成,对象包括数据和对数据进行操作的过程,过程通常称为方法或操作。对象在收到客户的请求(或消息)后,执行相应的操作。

1.2 不用设计模式情况

  • 扩展性:需求理解还很浅时,变化没有显现时,当某个功能第三次出现时
  • 重要性:不是系统的关键依赖点
  • 复用:项目没有复用价值时,或将要发布时

1.3 当满足设计模式的代码段需要重构时

  • 静态 → 动态
  • 早绑定 → 晚绑定
  • 继承 → 组合
  • 编译时依赖 → 运行时依赖
  • 紧耦合 → 松耦合

1.4 设计模式于python

  • 设计模式对于python契合度相对较低,因python为动态语言,且其中默认就集成了多种设计模式,设计模式也非一成不变,老的设计模式在消亡,新的在更新,无必要为了用设计模式而用设计模式。

二、SOLID原则

  • 单一职责原则(Single responsibility principle)

    一项功能或一类相似的功能,即只会有一个引起变化的地方。如果一个类承担的职责过多的话,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。只有单一职责的类才能更容易维护、扩展、复用

  • 开闭原则(Open Close Principle)

    软件实体(如类、模块、函数等)应该对拓展开放,对修改封闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。简言之,是为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类

  • 里氏代换原则(Liskov Substitution Principle)

    所有能引用基类的地方必须能透明地使用其子类的对象。里氏代换原则是继承复用的基石,只有当派生类可以替换掉基类,且软件单位的功能不受到影响时,基类才能真正被复用,而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化,而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范

  • 接口隔离原则(Interface Segregation Principle)

    客户端不应该依赖它不需要的接口。用多个细粒度的接口来替代由多个方法组成的复杂接口,每一个接口服务于一个子模块,我们要为不同类别的类建立专用的接口,而不要试图建立一个很庞大的接口供所有依赖它的类调用,如果接口过小,则会造成接口数量过多,使设计复杂化,在一个接口中,尽量不要又有查询又有更新(修改或插入)数据的操作

  • 依赖倒转原则(Dependence Inversion Principle)

    高层模块不应该依赖低层模块,抽象不应该依赖细节,二者都应该依赖其抽象,针对接口编程,而不是针对具体实现编程,相对于细节的多变性,抽象的东西要稳定的多,以抽象为基础搭建的架构比以细节为基础的架构要稳定的多,高层模块方法调用另一高层模块的对象

补充原则

  • 合成复用原则(Composite Reuse Principle)
    合成复用原则是指:尽量使用合成/聚合的方式,而不是使用继承
  • 迪米特法则(Demeter Principle)
    又称最少知道原则,一个类对自己依赖的类知道的越少越好,一个实体应当尽量少地与其他实体之间发生相互作用,使得系统功能模块相对独立。

三、设计模式分类

  • 设计模式可以分为三个大类:创建类设计模式、结构类设计模式、行为类设计模式

  • 创建类设计模式(5种)
    工厂模式(简单工厂模式)、抽象工厂模式、单例模式、建造者模式、原型模式

  • 结构类设计模式(7种)
    装饰器模式、代理模式、适配器模式、外观模式、组合模式、享元模式、桥梁模式

  • 行为类设计模式(10种)
    观察者模式、状态模式、策略模式、责任链模式、命令模式、中介者模式、模板模式、迭代器模式、访问者模式、备忘录模式

四、UML

4.1 概述

  • 功能:面向对象程序设计中,描述类及类间关系的图形化表示
  • 组成:类图、类间关系
  • 绘制工具:process,传送门

4.2 类图

在这里插入图片描述

4.3 类关系

4.3.1 继承

在这里插入图片描述

4.3.2 接口

  • 特性:不可以定义变量,定义的属性都是常量,方法均是抽象,侧重于实现关系
    在这里插入图片描述

4.3.3 关联

  • 关联:可以描述拥有关系,类间了解对方的属性及方法
    在这里插入图片描述

    • 箭头:指向拥有者,双向拥有可省略箭头
      双向拥有:老师可以拥有多名学生,学生也可以拥有多名老师
      单向拥有:一个班级拥有多名学生,一个学生只能属于一个班级
    • 字母:描述对象对应关系
      n-n:多对多关系,多个学生可以对应多个老师
      1-n:一对多关系,一个班级可以对应多个学生
  • 聚合:关联的子分类,关注体现集合个体关系,个体为独立的对象
    在这里插入图片描述

    • 箭头:指向个体,菱形指向集合
    • 字母:同关联
  • 组合:关联的子分类,关注体现整体部分关系,部分依赖整体存在
    在这里插入图片描述

    • 箭头:指向部分,菱形指向整体
    • 字母:同关联

4.3.4 依赖

  • 依赖:一个类的实现需要另一个类的协助,使用关系
    在这里插入图片描述
    • 箭头:由使用者指向被使用者

4.4 各种关系组合

  • 强弱顺序:

    泛化(继承关系) = 接口(实现关系) > 组合(整体与部分关系) > 聚合(集合与个体关系) > 关联(拥有的关系) > 依赖(使用的关系)

  • 形象地展示了各种类图关系:
    在这里插入图片描述


返回总目录

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值