Skip to content

Commit 7399697

Browse files
添加设计模式说明
1 parent 885736d commit 7399697

File tree

3 files changed

+919
-628
lines changed

3 files changed

+919
-628
lines changed

go/go.md

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -30,6 +30,35 @@ func main() {
3030
}
3131
```
3232

33+
**闭包就是一个函数与相关的引用环境组成的一个整体(实体)**
34+
35+
Go 语言支持匿名函数,可作为闭包。匿名函数是一个"内联"语句或表达式。匿名函数的优越性在于可以直接使用函数内的变量,不必申明。
36+
37+
> 在本质上,闭包是函数内部和函数外部连接起来的桥梁,或者说是函数和其引用环境的组合体
38+
39+
闭包存在延迟绑定,其实质是因为闭包是采用的引用方式进行闭包,就算是值类型,一旦被匿名函数闭包值也是采用的引用
40+
```go
41+
func foo5() {
42+
values := []int{1, 2, 3, 5}
43+
// 注意如果这里val值是range创建 _, val := range values将会闭包很多变量,不能实现全部都输出5的效果
44+
val := 0
45+
for _, val = range values {
46+
go func() {
47+
fmt.Printf("foo5 val = %v\n", val)
48+
}()
49+
}
50+
}
51+
52+
foo5()
53+
//foo3 val = 5
54+
//foo3 val = 5
55+
//foo3 val = 5
56+
//foo3 val = 5
57+
```
58+
其实也很好理解,如果学过C语言,val的值拿的是引用,当执行闭包的函数时,会重新索引val的值
59+
60+
61+
3362
https://blog.csdn.net/u010429831/article/details/108641919[闭包]
3463

3564
## 关键字
@@ -1135,6 +1164,21 @@ go tool compile -S pkg.go
11351164
```
11361165

11371166

1167+
```go
1168+
package main
1169+
1170+
func main() {
1171+
_ = add(3,5)
1172+
}
1173+
1174+
func add(a, b int) int {
1175+
return a+b
1176+
}
1177+
```
1178+
1179+
`go tool compile -S main.go`
1180+
1181+
11381182

11391183

11401184

@@ -1252,6 +1296,10 @@ taskset -c 0 perf bench sched pipe -T
12521296

12531297

12541298

1299+
[GMP原理](https://www.topgoer.com/%E5%B9%B6%E5%8F%91%E7%BC%96%E7%A8%8B/GMP%E5%8E%9F%E7%90%86%E4%B8%8E%E8%B0%83%E5%BA%A6.html)
1300+
1301+
1302+
12551303

12561304

12571305
## 文章

go/设计模式.md

Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
2+
## 设计模式的类型
3+
4+
1. **单一职责原则**:一个类只负责一项职责,或者说一个类只有一个引起它变化的原因。
5+
2. **开放封闭原则**:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
6+
3. **里氏替换原则**:所有引用基类的地方必须能透明地使用其子类的对象。
7+
4. **依赖倒置原则**:抽象不应该依赖于细节,细节应该依赖于抽象。
8+
5. **接口隔离原则**:使用多个专门的接口,而不使用单一的总接口。
9+
6. **合成复用原则**:尽量使用对象组合,而不是继承来达到复用的目的。
10+
7. **迪米特法则**:一个软件实体应当尽可能少地与其他实体发生相互作用。
11+
8. **最少知识原则**:一个软件实体应当尽可能少地与其他实体发生相互作用。
12+
9. **单例模式**:保证一个类仅有一个实例,并提供一个访问它的全局访问点。
13+
10. **工厂方法模式**:定义一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
14+
11. **抽象工厂模式**:提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
15+
12. **建造者模式**:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
16+
13. **原型模式**:用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。
17+
14. **适配器模式**:将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
18+
15. **桥接模式**:将抽象部分与它的实现部分分离,使它们都可以独立地变化。
19+
16. **装饰模式**:动态地给一个对象添加一些额外的职责。就增加功能来说,装饰模式相比生成子类更为灵活。
20+
17. **外观模式**:为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
21+
18. **享元模式**:运用共享技术有效地支持大量细粒度的对象。
22+
19. **代理模式**:为其他对象提供一种代理以控制对这个对象的访问。
23+
20. **组合模式**:将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
24+
21. **模板方法模式**:定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
25+
22. **策略模式**:定义一系列的算法,把它们一个个封装起来,并且使它们可以相互替换。
26+
23. **命令模式**:将一个请求封装成一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。
27+
24. **职责链模式**:使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。
28+
25. **迭代器模式**:提供一种方法顺序访问一个聚合对象中各个元素,而又不暴露该对象的内部表示。
29+
26. **观察者模式**:定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。
30+
27. **中介者模式**:用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。
31+
28. **备忘录模式**:在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
32+
29. **解释器模式**:给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。
33+
30. **状态模式**:允许一个对象在其内部状态改变时改变它的行为能力。
34+
31. **访问者模式**:表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
35+
32. **享元模式**:运用共享技术有效地支持大量细粒度的对象。
36+
33. **代理模式**:为其他对象提供一种代理以控制对这个对象的访问。
37+
34. **适配器模式**:将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
38+
35. **装饰模式**:动态地给一个对象添加一些额外的职责。就增加功能来说,装饰模式相比生成子类更为灵活。
39+
36. **桥接模式**:将抽象部分与它的实现部分分离,使它们都可以独立地变化。
40+
37. **组合模式**:将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
41+
38. **外观模式**:为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
42+
39. **策略模式**:定义一系列算法,把他们一个个封装起来,并且使他们可以相互替换。
43+
40. **模板方法模式**:定义一个操作中算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
44+
45+
46+
47+
48+
| **模式名称** | **模式名称** | **作用** |
49+
| ----------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
50+
| **创建型模式** **Creational Pattern(6)** | 单例模式★★★★☆ | 是保证一个类仅有一个实例,并提供一个访问它的全局访问点。 |
51+
| 简单工厂模式★★★☆☆ | 通过专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。 | |
52+
| 工厂方法模式★★★★★ | 定义一个创建产品对象的工厂接口,将实际创建工作推迟到子类中。 | |
53+
| 抽象工厂模式★★★★★ | 提供一个创建一系列相关或者相互依赖的接口,而无需指定它们具体的类。 | |
54+
| 原型模式★★★☆☆ | 用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。 | |
55+
| 建造者模式★★☆☆☆ | 将一个复杂的构建与其表示相分离,使得同样的构建过程可以创建不同的表示。 | |
56+
| **结构型模式Structural Pattern(7)** | 适配器模式★★★★☆ | 将一个类的接口转换成客户希望的另外一个接口。使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 |
57+
| 桥接模式★★★☆☆ | 将抽象部分与实际部分分离,使它们都可以独立的变化。 | |
58+
| 组合模式★★☆☆☆ | 将对象组合成树形结构以表示“部分--整体”的层次结构。使得用户对单个对象和组合对象的使用具有一致性。 | |
59+
| 装饰模式★★★☆☆ | 动态的给一个对象添加一些额外的职责。就增加功能来说,此模式比生成子类更为灵活。 | |
60+
| 外观模式★★★★★ | 为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。 | |
61+
| 享元模式★☆☆☆☆ | 以共享的方式高效的支持大量的细粒度的对象。 | |
62+
| 代理模式★★★★☆ | 为其他对象提供一种代理以控制对这个对象的访问。 | |
63+
| **行为型模式Behavioral Pattern(11)** | 职责链模式★★☆☆☆ | 在该模式里,很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求,这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任。 |
64+
| 命令模式★★★★☆ | 将一个请求封装为一个对象,从而使你可用不同的请求对客户端进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。 | |
65+
| 解释器模式★☆☆☆☆ | 如何为简单的语言定义一个语法,如何在该语言中表示一个句子,以及如何解释这些句子。 | |
66+
| 迭代器模式★☆☆☆☆ | 提供了一种方法顺序来访问一个聚合对象中的各个元素,而又不需要暴露该对象的内部表示。 | |
67+
| 中介者模式★★☆☆☆ | 定义一个中介对象来封装系列对象之间的交互。终结者使各个对象不需要显示的相互调用 ,从而使其耦合性松散,而且可以独立的改变他们之间的交互。 | |
68+
| 备忘录模式★★☆☆☆ | 是在不破坏封装的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。 | |
69+
| 观察者模式★★★★★ | 定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。 | |
70+
| 状态模式★★☆☆☆ | 对象的行为,依赖于它所处的状态。 | |
71+
| 策略模式★★★★☆ | 准备一组算法,并将每一个算法封装起来,使得它们可以互换。 | |
72+
| 模板方法模式★★★☆☆ | 得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 | |
73+
| 访问者模式★☆☆☆☆ | 表示一个作用于某对象结构中的各元素的操作,它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。 | |

0 commit comments

Comments
 (0)