• #设计模式#GeekBand设计模式第一周课程


    今天看了李老师的设计模式,晚上在此通过记忆整理一下,明天再根据笔记详细整理。

    ————————通过记忆整理————————————————————————

    设计原则 比 设计模式 更本质

    目前常用的设计模式有23种,然而这都是方法,更重要的是其中本质的东西:设计原则,设计思想。

    分解和抽象

    面向对象的三个重要概念是:1、封装  2、继承 3、多态 但是这三个概念都是底层的,在上层上需要使用“抽象”的思想去处理问题。

    分解:分而治之,这是人们经常使用的解决问题的方法,其基本思想是把问题拆分开来处理

    抽象:将问题统一起来看待,找到不考虑细节、更理想化的模型

    设计模式的目标是:复用

    当处理一个简单,或者不需要变化的问题时,设计模式的不同影响不大。

    然而一旦出现变化(客户需求变化,开发平台变化,开发人员变化),那么设计模型的作用就体现出来了。

    在一系列设计原则的指导下,可以尽可能小的修改代码,就应付出现的变化。

    设计原则

    李老师提到了好几条设计原则,

    我记忆最深的是三个思想:

    1、向下依赖

    稳定的模块不要依赖变化的模块。

    2、各司其职

    每个代码完成其对应的工作,比如“打印”,该类需要被打印,那么就自己实现打印函数。

    这样其他类通过该类的基类的虚函数就可以调用该类的函数(多态性)。

    3、继承和组合。

    如果子类不会使用父类的太多函数,可以考虑使用“组合”的模式,而不是“继承”的模式。

    继承其实在一定程度上破坏了“封装”,增加了耦合

    ————————通过笔记整理————————————————————————

    ***********第一讲开始********************************************

    设计模式主要是一种松耦合设计思想

    每一种设计模式,其实是针对某个重复出现的问题,提出的解决方案

    在编程过程中,向下是底层思维,向上是抽象思维

    底层思维 抽象思维

    语言构造

    编译转换

    内存模型

    运行时机制

    面向对象

    组件封装

    设计模式

    架构模式

    对于问题,人们常用两种解决方法

    分解

    将问题分解成一个一个的步骤,

    建立一个类A类B

    如果类C需要使用类A的信息,就包含类A类B作为成员

    如果类C需要打印类A的信息,就在类C中撰写打印类A类B的函数

    抽象

    由于不能掌握全部的复杂对象,选择忽视它的非本质细节,而去处理泛化和理想化的模型

    类C并不知道需要为哪个类服务,需要它选择为类A类B的基类服务

    类A类B各自实现功能,可以通过虚函数去调用

    如果类C需要打印类A,就通过虚函数,动态调用类A的打印函数;

    如果类C需要打印类A,就通过虚函数,动态调用类B的打印函数;

    软件设计的目标是:复用

    ***********第一讲结束,第二讲开始********************************************

    在代码不出现变化的时候,设计模式的优势看不出来,而一旦出现变化,好的设计模式的作用就体现出来了。

    面向对象的最大优势是:抵御变化

    重新认识面向对象:

    1、宏观角度。隔离变化

    2、微观角度(具体实现角度)。各个部分各司其职,完成各自的功能。

    3、对象是什么?

    从语言实现角度,对象就是代码和数据的集合

    从规格层面,对象是一系列可被使用的公共接口

    从概念角度,对象是拥有责任的抽象

    面向对象设计模型的8大原则

    依赖倒置原则(DIP)

    1、高层模块(稳定)不应该依赖于低层模块(变化),二者都依赖于抽象(稳定)

    2、抽象(稳定)不应该依赖于实现细节(变化),实现细节应该依赖于抽象(稳定)

    稳定不能依赖变化

    开放封闭原则(OCP)

    对扩展开放,对更改封闭

    类模块应该是可扩展的,但不可修改

    (对于“变化”,用“增加”去应对)

    单一职责原则(SRP)

    一个类应该仅有一个引起它变化的原因

    (变化的方向隐含类的责任)

    Liskov替换原则(LSP)

    子类必须能够替换它们的基类(反映的是is-A的关系)

    接口隔离原则(ISP)

    不应该强迫客户程序依赖它们不用的方法

    接口要小而完备

    优先使用对象组合,而不是类继承

    类继承通常是“白箱复用”,对象组合通常为“黑箱复用”

    继承在某种程度上破坏了封装性,子类父类的耦合度高

    而对象组合只要求对象有良好定义的接口

    封装变化点 使用封装来创建对象之间的分界层,让设计者可以只对一侧进行修改,而不影响另外一侧
    针对接口编程,而不是针对实现编程

    不将变量类型声明为某个特定的具体类,而是声明为某个接口

    客户程序无需知道对象的具体类型,只需要知道接口

    (老师提到,产业强盛的标志是“接口标准化”)

       

    纸上学来终觉浅,绝知此事要躬行。

    设计模式,还需要多体会。

  • 相关阅读:
    js对象的sessionStorage,判断对象相等,判断是否包含某属性
    vant-ui的van-area使用
    JavaScript返回格式化的时间字符串
    vant-ui的van-uploader上传图片
    移动端vue页面禁止移动/滚动
    vue项目中的跨域源请求拦截问题CORS头缺少'Access-Control-Allow-Origin'
    项目开发过程中踩坑和填坑
    周报
    构建一个最简单的react程序
    Socket实现简易“多人聊天室”
  • 原文地址:https://www.cnblogs.com/wuqi/p/4719735.html
Copyright © 2020-2023  润新知