设计模式原则

什么是设计模式

设计模式是针对软件开发过程中遇到的一些设计问题,总结出来的一套解决方案或者设计思路。

https://zh.wikipedia.org/wiki/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F_(%E8%AE%A1%E7%AE%97%E6%9C%BA)
在这里插入图片描述

创建型模式

  • 简单工厂模式(Simple Factory)
  • 工厂方法模式(Factory Method)
  • 抽象工厂模式(Abstract Factory)
  • 创建者模式(Builder)
  • 原型模式(Prototype)
  • 单例模式(Singleton)

结构型模式

  • 外观模式(Facade)
  • 适配器模式(Adapter)
  • 代理模式(Proxy)
  • 组合模式(Composite)
  • 享元模式(Flyweight)
  • 装饰模式(Decorator)
  • 桥模式(Bridge)

行为型模式

  • 中介者模式(Mediator)
  • 观察者模式(Observer)
  • 命令模式(Command)
  • 迭代器模式(Iterator)
  • 模板方法模式(Template Method)
  • 策略模式(Strategy)
  • 状态模式(State)
  • 备忘录模式(Memento)
  • 解释器模式(Interpreter)
  • 职责链模式(Chain of Responsibility)
  • 访问者模式(Visitor)

面向对象

面向对象编程是一种编程方式或者编程风格, 以类或者对象作为组织代码的基本单元。包含封装,多态,继承,抽象等4个基本特性。

面向对象语言

面向对象语言是支持类和对象的语法机制,并有现在的语法机制,能够方便的实现面向对象的4大特征(封装、抽象、继承、多态)的编程语言。封装特性存在的意义,一方面是保护数据不被随意修改,提高代码的可维护性;另一方面是仅暴露有限的必要接口,提高类的易用性。

封装

封装也叫做数据隐藏和数据访问保护,通过暴露有限的访问接口,授权外部仅能通过类提供的方式来访问内部信息和数据。它需要编程语言提供权限访问控制语法来支持, 比如 Java 中的 private 、protected 、public等关键字。

抽象

封装说的是如何隐藏信息和保护数据,抽象说的是如何隐藏方法的具体实现,抽象可以通过接口或者抽象类来实现,但也并不需要特定的语法来支持。抽象存在的意义,一方面是提高代码的可扩展性和维护性, 修改方法时不需要改变定义,减少代码的改动范围,另外一方面也是处理复杂问题的有效手段, 能够有效过滤掉不需要关注的信息

继承

继承用来表示 类之间 is-a 的关系,分为两种模式, 单继承和多继承,单继承表示一个子类只能继承一个父类,多继承表示一个子类可以继承多个父类,为了实现继承这个特性,编程语言需要提供特殊的语法机制来支持。继承主要是用来解决代码复用的问题。

多态

子类可以替代父类,实际代码运行过程中,调用子类的方法实现。 多态这个特性需要编程语言的特殊语法机制来实现,比如继承、接口类,duck-typing, 多态可以提高代码的扩展性和复用性,有很多设计模式,设计原则,编程技巧的代码实现基础。

面向对象和面向过程

  • 对于大规模复杂程序的开发,程序的处理并非单一的一条主线,是错综复杂的网状结构,面向对象比面向过程编程,更能够应对这种复杂类型的程序开发。
  • 面向对象编程相对于面向过程编程,具有丰富的特性(抽象,继承,封装,多态),利用这些特性写出的代码更加容易扩展,易复用,易维护。
  • 面向对象编程比面向过程编程更加人性化,更加智能。

组合与继承

  • 继承是面向对象的四大特性之一,表示类之间的 is-a 的关系(Apple is Fruit ) 可以解决代码复用的问题,但是继承如果层次过深,过复杂,也会影响代码的可维护性。
  • 组合表示的是类的 has-a 的关系,比如 House has BathRoom 。

类的继承层次如果很深,继承的关系会越来越复杂,而且层次很深很复杂的继承关系,会导致代码可读性变差,子类的实现依赖父类的实现,两者高度耦和,一旦父类代码修改,会影响子类的逻辑。

GO 是面向对象语言么?

Go 围绕 struct ,提供了私有属性、method、interface、struct 嵌套能力,可以用更轻量的方式实现面向对象(封装,继承,多态,抽象)

Go 核心理论

基于接口编程而非实现编程

接口是一组协议或者约定,是功能提供者提供给使用者的一个功能列表,接口在不同的场景下有不同的解读,

好的代码设计,不仅能够应对当下需求,而且在将来需求发生变化的时候,仍然可以在不破坏原有代码设计的情况下灵活应对。

设计原则

在这里插入图片描述

如何理解单一职责原则 (SRP)

一个类或者一个模块只负责完成一个职责或者功能,不要设计大而全的类, 要设计粒度小,功能单一的类, 单一职责是为了实现代码高内聚,低耦合,提高代码的复用性,可读性,可维护性。

如何判断类的职责是否足够单一

不同应用的场景,不同阶段的需求背景,不同的业务层面,对通一个类的职责是否单一,可能会有不同的判定结果。

如果出现以下情况,表示不满足单一职责原则:

  • 类中的代码行数,函数或者属性过多
  • 类依赖其他类过多, 或者依赖类的其他类过多
  • 私有方法过多
  • 比较难给类取一个合适的名字
  • 类中大量方法都集中在操作类的某些属性上
  • 代码中存在大量注释

开闭原则

如何理解 “对扩展开放,对修改关闭”

添加一个新功能,应该是通过现有共扩展代码(新增模块,类,方法,属性等), 而非修改已有代码的方式来完成。

  • 第一点,开闭原则并不少说完全杜绝修改,而是以最小的修改代码的代价完成新功能的开发。
  • 第二点,同样的代码修改,在粗粒度下,可以被认为是修改,在细粒度下,被认为是“扩展”。

我们对一个类添加新的方法。添加方法相当于修改类,在类这个层面,这个代码改动可以被认定为“修改”;但这个代码改动并没有修改已有的属性和方法,在方法(及其属性)这一层面,它又可以被认定为“扩展”

如何做到修改关闭,扩展开放?

时刻具备扩展意识,抽象意识,封装意识。编码时,要多花时间去思考,代码未来可能哪些需求变更,如何设计代码结构,事先留好扩展点,以便在未来在需求变更时,在不调整代码结构的基础上,做到最小代码的修改,将新代码灵活的放到扩展点上。

最常用的提高代码扩展的方法有:多态,依赖注入, 基于接口而非实现编程,与大部分设计模式。

里式替换

里式替换原则的英文翻译是:Liskov Substitution Principle,缩写为 LSP。这个原则最早是在 1986 年由 Barbara Liskov 提出,他是这么描述这条原则的:
If S is a subtype of T, then objects of type T may be replaced with objects of type S, without breaking the program。

子类对象能给替换程序中父类出现的任何对方,并且保证程序的行为逻辑及正确性不被破坏。

多态是面向对象编程等一大特性,也是面向对象编程语言的一种语法,它是一种代码实现的思路,里式转换原则设计中,是用来指导继承关系中子类如何设计,子类的设计保证在替换父类时,不改变原有逻辑和程序的正确性。

接口隔离

接口隔离原则的英文翻译是“ Interface Segregation Principle”,缩写为 ISP。Robert Martin 在 SOLID 原则中是这样定义它的:“Clients should not be forced to depend upon interfaces that they do not use。”直译成中文的话就是:客户端不应该被强迫依赖它不需要的接口。其中的“客户端”,可以理解为接口的调用者或者使用者。

理解接口隔离重要是理解其中接口两字。
接口理解一组接口集合,可以是某个服务的接口,可以是某个类的接口,如果部分接口被有这使用。

接口隔离原则和单一职责原则的区别

单一职责是针对的是类,模块,接口的设计,接口隔离原则相对单一原则更侧重于接口的设计。另外思考角度也不一样。接口隔离原则提供了一种判断接口是否单一的标准:通过调用者如何使用接口来判断,如果调用者使用部分接口或接口的部分功能,那接口的设计就不够单一

依赖倒置原则

控制反转

实际上,控制反转是一个比较笼统的设计思想,并不是一种具体的实现方法,一般用来指导框架层面的设计。这里所说的“控制”指的是对程序执行流程的控制,而“反转”指的是在没有使用框架之前,程序员自己控制整个程序的执行。在使用框架之后,整个程序的执行流程通过框架来控制。流程的控制权从程序员“反转”给了框架。

依赖注入

依赖注入和控制反转恰恰相反,它是一种具体的编码技巧。我们不通过 new 的方式在类内部创建依赖类的对象,而是将依赖的类对象在外部创建好之后,通过构造函数、函数参数等方式传递(或注入)给类来使用。依赖注入也是实现组合最简单的方式

type A struct {}

func NewA() A {
    return A{}
}

type B struct {
    a A
}

func NewB(a A) B {
    return B{a:a}
}

func main() {
    a := NewA()
    // 依赖注入
    b := NewB(a)
}

依赖反转原则也叫作依赖倒置原则。这条原则跟控制反转有点类似,主要用来指导框架层面的设计。高层模块不依赖低层模块,它们共同依赖同一个抽象。抽象不要依赖具体实现细节,具体实现细节依赖抽象。

KISS 原则

  • Keep It Simple and Stupid.
  • Keep It Short and Simple.
  • Keep It Simple and Straightforward.

其实主要含义是尽量保持简单

如何写出 KISS 原则的代码

  • 不要使用同事可能不懂的技术来实现代码
  • 不要重复造轮子,要善于使用已经有的工具类库
  • 不要过度优化

DRY 原则

DRY 原则(Don’t Repeat Yourself)几乎人尽皆知。你可能会觉得,这条原则非常简单、非常容易应用。只要两段代码长得一样,那就是违反 DRY 原则了。真的是这样吗?答案是否定的。这是很多人对这条原则存在的误解。实际上,重复的代码不一定违反 DRY 原则,而且有些看似不重复的代码也有可能违反 DRY 原则。

通常存在三种典型的代码重复情况,它们分别是:实现逻辑重复、功能语义重复和代码执行重复

问题:如何提高代码复用性?

  • 减少代码耦合
  • 满足单一职责原则
  • 模块化业务与非业务逻辑分离
  • 通用代码下沉
  • 继承、多态、抽象、封装
  • 应用模板等设计模式

LOD 原则

迪米特法则的英文翻译是:Law of Demeter,缩写是 LOD。单从这个名字上来看,我们完全猜不出这个原则讲的是什么。不过,它还有另外一个更加达意的名字,叫作最小知识原则,英文翻译为:The Least Knowledge Principle。

迪米特法则法则强调不该有直接依赖关系的类之间,不要有依赖;有依赖关系的类之间,尽量只依赖必要的接口。迪米特法则是希望减少类之间的耦合,让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化,需要了解这一变化的类就会比较少。

“单一职责原则”、“接口隔离原则”以及“最小知识原则”,都是实现高内聚低耦合的有效指导思想。“最小知识原则”更强调类与类之间的关系。

欢迎关注:程序员开发者社区

在这里插入图片描述

参考资料

  • https://github.com/senghoo/golang-design-pattern
  • https://www.cnblogs.com/wuyuegb2312/p/7011708.html
  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
©️2020 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值