Golang设计模式整理

我就是小政政 · · 1907 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

UML类图

研究设计模式首先要掌握类图,类图也就是表达模型之前的关系。
UML—Unified modeling language UML (统一建模语言)


image.png
image.png

设计原则

先复习一下6大设计原则,对他们的理解

单一职责(SRP Single Responsibility Principle)

一个类或一个方法只有一个职责,尽量做到只有一个行为原因引起变化。
理解:

  1. 降低类的复杂度,一个类只负责一项职责。
  2. 提高类的可读性,可维护性
  3. 降低变更引起的风险
  4. 通常情况下,我们应当遵守单一职责原则,只有逻辑足够简单,才可以在代码级违反单一职责原则;只有类中
    方法数量足够少,可以在方法级别保持单一职责原则
接口隔离原则(ISP Interface Segregation Principle)

客户端不应该依赖它不需要的接口,一个类对另一个类的依赖应该建立在最小接口上。
理解:一些接口内聚性不够,可能同时做了很多事情。这时候需要拆分让每个接口恰好做一件事。有的接口从逻辑上确实是一件事但是还可以细分这取决于一个度(根据需求推敲出的度)。如果逻辑上实在分不出来,可以从二八原则上来区分,同一个接口中80%时候使用的方法与20%时候使用的方法是可以分开的。来增加灵活性,它的意义就是省去了必须要去实现一些不需要实现的接口。同时接口隔离也能降低里式替换原则中担心的替换、修改父类对子类的影响。还有这也符合迪米特法则,不该知道的就无需知道,否则一旦调用了无需实现的接口方法存在一定的风险。

依赖倒置原则(DIP Dependence Inversion Principle)

1)高层模块不应该依赖底层模块,二者都应该依赖抽象
2)抽象不应该依赖与细节,细节应该依赖抽象
3)中心思想是面向接口编程
4)理念:相对于细节的多变性,抽象稳定得多。以抽象为基础搭建的架构比以细节搭建的架构稳定的多
5)使用接口或抽象类的目的是制定好规范,而不涉及具体的操作,把展现细节交给实现类去完成。

里氏替换原则(LSP liskov substitution principle)

子类可以扩展父类的功能,但不能改变原有父类的功能,
理解:继承带来便利的同时,也增加了侵入性。使耦合性增强了,如果要修改一个类那么必须要考虑到对它的子类的影响。所以里式替换指出:子类尽量不要重写父类的方法。适当情况下可以通过聚合、组合等方式来解决问题。

迪米特法则(LoD Law of Demeter)

1)直接的朋友:出现在方法参数、方法返回值、成员变量中的是直接的朋友;出现在局部变量中的不是直接的朋友。只与朋友通信。
2)一个对象应该对其他对象保持最小的了解。一个类对自己依赖的类知道的越少越好,尽量将逻辑封装在类的内部,对外除了提供public方法外不透露任何信息。
3)理解:通过访问权限,类无需暴露自己的缺陷给外部;观察直接的朋友,这些都是可以通过依赖倒置原则使用抽象来替换的部分;另外重要的是确认你真正的朋友,并且只和朋友说话,不和陌生人说话,对哪些应该是朋友,哪些不应该是朋友需要重点划分。

开闭原则(OCP Open Source Principle)

对扩展开放(对提供方),对修改关闭(对使用方)。
理解:设计模式的核心就是为了管控变化。最理想的形式就是增加、修改了功能后,使用方无需变化或者只需要新增而其他的不变。不可避免的是肯定会有功能的修改,要做的就是去找出稳定的部分,通过统一的调用位置来管控能预测到的变化,让稳定的部分不受影响,让变化的部分能够快速支持。

具体设计模式


有疑问加站长微信联系(非本文作者)

本文来自:简书

感谢作者:我就是小政政

查看原文:Golang设计模式整理

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1907 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传