读书笔记----软件设计原则、设计模式

| 这个作业属于哪个课程 |2021软件代码开发技术 |

| ----------------- |--------------- |

| 这个作业要求在哪里 | 读书笔记----软件设计原则、设计模式 |

| 这个作业的目标 | 对软件设计原则、设计模式的心得体会 |

参考书籍

  • 朱洪军《软件设计模式》

1.总结软件设计的原则

(1)依赖倒置原则
1、高层模块不应该依赖低层模块,二者都依赖抽象
2、抽象不应该依赖于实现细节,实现细节应该依赖于抽象
(2)开放封闭原则
1、对扩展开放,对更改封闭
2、类模块应该是可扩展的,但是不可修改
(3)接口隔离原则
1、客户端不应该依赖它不需要的接口
2、一个类对另一个类的依赖应该建立在最小的接口上
(4)单一职责原则
1、一个类只负责一项职责
(5)迪米特法则
1、如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用
2、 如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用
(6)里式替换原则
1、子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法
2、子类中可以增加自己特有的方法

2.总结软件设计的模式

三个类别,23种方法

  • 创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

  • 结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

  • 行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

  • 创造型
    | 方法 | 内容 |
    | ----------------- |--------------- |
    |工厂方法|定义一个用于创建对象的接口,让子类决定实例化哪一个类,Factory Method使一个类的实例化延迟到了子类|
    |单例模式| 保证一个类只有一个实例,并提供一个访问它的全局访问点,限制了创建类的实例数量|
    |抽象工厂| 提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们的具体类|
    |建造模式| 将一个复杂对象的构建与他的表示相分离,使得同样的构建过程可以创建不同的表示|
    |原型模式| 用原型实例指定创建对象的种类,并且通过拷贝这些原型来创建新的对象|

  • 结构型
    | 方法 | 内容 |
    | ----------------- |--------------- |
    |组合模式| 将对象组合成树形结构以表示部分整体的关系,Composite使得用户对单个对象和组合对象的使用具有一致性|
    |外观模式| 为子系统中的一组接口提供一致的界面,facade提供了一高层接口,这个接口使得子系统更容易使用|
    |代理模式| 为其他对象提供一种代理以控制对这个对象的访问|
    |适配器模式| 将一类的接口转换成客户希望的另外一个接口,此模式使得原本由于接口不兼容而不能一起工作那些类可以一起工作。使不兼容的接口匹配|
    |装饰模式| 动态地给一个对象增加一些额外的职责,就增加的功能来说,Decorator模式相比生成子类更加灵活|
    |桥模式| 将抽象部分与它的实现部分相分离,使他们可以独立的变化|
    |享元模式| 使用共享物件,用来尽可能减少内存使用量以及分享资讯给尽可能多的相似物件;它适合用于当大量物件只是重复因而导致无法令人接受的使用大量内存|

  • 行为型
    | 方法 | 内容 |
    | ----------------- |--------------- |
    |迭代器模式| 提供一个方法顺序访问一个聚合对象的各个元素,而又不需要暴露该对象的内部表示|
    |观察者模式| 定义对象间一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知自动更新。ex:监听一个事件状态,让它在状态发生改变时主动发出通知|
    |模板方法| 定义一个操作中的算法的骨架,而将一些步骤延迟到子类中,TemplateMethod使得子类可以不改变一个算法的结构即可以重定义该算法得某些特定步骤|
    |命令模式| 将一个请求封装为一个对象,从而使你可以用不同的请求对客户进行参数化,对请求排队和记录请求日志,以及支持可撤销的操作|
    |状态模式| 允许对象在其内部状态改变时改变他的行为。对象看起来似乎改变了他的类|
    |策略模式| 定义一系列的算法,把他们一个个封装起来,并使他们可以互相替换,本模式使得算法可以独立于使用它们的客户|
    |职责链模式| 使多个对象都有机会处理请求,从而避免请求的送发者和接收者之间的耦合关系|
    |中介者模式| 用一个中介对象封装一些列的对象交互|
    |访问者模式| 表示一个作用于某对象结构中的各元素的操作,它使你可以在不改变各元素类的前提下定义作用于这个元素的新操作|
    |解释器模式| 给定一个语言,定义他的文法的一个表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子|
    |备忘录模式| 在不破坏对象的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态|

3.心得体会

在阅读的过程中,往往单从文字上很难与作者产生共鸣的,通过应用才可以更加深刻得理解,文字背后的含义
实践才能出真知,开发代码需要多写多练,只有经过自己的理解与练习,才会变成自己的东西
这里列举了依赖倒置原则的作用,在开发中应用这种模式有时会让代码更加简洁
下面为代码示例:

class DrawingBoard{//绘画板,代表高层模块
        var lineArray:Array<Line>?
        var rectArray:Array<Rect>?
        func onPaint(){
            for lineInstance in lineArray{
                 event.Graphics.DrawLine(Pens.Red,
                  lineInstance.leftUp,
                  lineInstance.width,
                  lineInstance.height)
             }
            for rectInstance in rectArray{
                 event.Graphics.DrawRect(Pens.Red,
                  rectInstance.leftUp,
                  rectInstance.width,
                  rectInstance.height)
             }
         }
       
   }
  class Line{//底层模块(代表容易变化的模块)
       func Draw(){ ... }
   }
  class Rect{//底层模块(代表容易变化的模块)
        func Draw(){ ... }

而应用依赖倒置设计原则之后可以这样去修改:

class DrawingBoard{//绘画板,代表高层模块
        var shapeArray:Array<Shape>?
        func onPaint(){
             for shape in shapeArray{
                  shape.Draw();
             }
         }
   }
  protocol Shape{//抽象接口,同时也是一种稳定的模块(高层和低层都依赖抽象类)
        func Draw(){  }
   }
  class Line:Shape{//底层模块(代表容易变化的模块)
        override func Draw() {  }//实现细节应该依赖于抽象
   }
  class Rect:Shape{//底层模块(代表容易变化的模块)
        override func Draw() {  }//实现细节应该依赖于抽象
   }

markdowm截图

posted @ 2021-03-17 21:29  ccgccg  阅读(115)  评论(0)    收藏  举报