用Go语言实现23种设计模式及学习重点
今天是咱们用Go学设计模式系列的最后一期，整个系列中我带着大家一起学习了经典的23种设计模式用Go语言如何来实现，以及它们在日常工作开发中的应用场景。
我看了一下发文记录，从2022年7月18更新第一篇观察者模式，到5月22号发布了最后一种设计模式--中介者模式，一共历时10个月，发布了23篇文章。从最一开始的不准备整理成系列写到哪算哪，到中期形成自己的写作风格，有目标的去学习整理再发布，对自己来说确实算是一个小小的成就。
今天我们给系列来个收尾，跟大家谈谈写程序需要用到设计模式吗？设计模式学习的重点是什么，以及整理一下咱们这个系列分享的用Go学23种设计模式的合订本。
写程序需要用设计模式吗？
这个问题可以延伸出多个子问题，写Go程序需要用设计模式吗？写python程序需要用设计模式吗，写Java / C# 需要用设计模式吗？ Java 和 C# 这种在企业领域生根发芽、枝繁叶茂多年的语言本身提供的编程接口就用了很多设计模式，所以大部分人都觉得需要。
而针对Go 或者 Python 这种秉承少即是多，在编程语言界有点特立独行的语言，他们写程序时需要用设计模式吗？
我觉得是需要的，因为设计模式的思想是通的，并且我们一直都在使用，只要咱们想让自己写的程序变得可维护、可复用、可扩展、灵活性好，那势必要遵循设计模式的六大原则的，哪些六大原则呢？咱们下部分再细说。
这里我们要谨记请勿使用其他语言的方式套用到Go语言上来实现设计模式，那样你会发现类似 JAVA 的这些面向对象语言中的某些设计模式的写法用在 Go 语法中会十分的别扭。
这也是我更新这个系列文章的目的，这两年带的团队里Java 和 Go 都在用，但是Go写出来的代码总感觉怪怪的，要不完全没设计模式摊大饼一样搞几千行，要不就硬搬Java的思路去实现。
所以我在这个系列里给设计模式写代码示例时，花了相当的篇幅给大家标出Go 和 其他面向对象语言在实现某个模式上的区别等等。这个大家可以在文章的代码讲解和注释中看到。
学习设计模式的重点
设计模式对于程序员而言并不陌生，每个程序员在编程时都会或多或少地接触到设计模式。无论是在大型程序的架构中，亦或是在源码的学习中，设计模式都扮演着非常重要的角色。
关于设计模式的态度，我相信有时候大部分人都会有这种感觉，即使按部就班地学了书上介绍的所有设计模式，在实践中也应用不好，写出来不知道它属于哪种设计模式。
这个很正常，因为在实践中，程序的作者往往是需要根据实际的上下文对模式进行变种，或者两种或者多种设计模式结合使用来设计程序的，所以从整体看你说不好它用了哪种设计模式，只能说是挑选一个视角观察程序结构，看到它在某个环节应用了某个设计模式，整个程序往往是多个模式的结合。
其实GoF 23 中列举的这些个经典的设计模式相当于是前人们为我们列举出了程序遵循的六大设计原则的各种最佳实践的示例，相当于为我们提供了一个切入点，让我们能通过它们来学习、理解、应用这六个原则。
从开始我们一直在说用设计模式的目的是让程序遵守六大原则，现在我们一起来看一下这六大原则。
设计模式基于六大原则：
- 开闭原则：一个软件实体如类、模块和函数应该对修改封闭，对扩展开放。
- 单一职责原则：一个类只做一件事，一个类应该只有一个引起它修改的原因。
- 里氏替换原则：子类应该可以完全替换父类。也就是说在使用继承时，只扩展新功能，而不要破坏父类原有的功能。
- 依赖倒置原则：细节应该依赖于抽象，抽象不应依赖于细节。把抽象层放在程序设计的高层，并保持稳定，程序的细节变化由低层的实现层来完成。
- 迪米特法则：又名「最少知道原则」，一个类不应知道自己操作的类的细节，换言之，只和朋友谈话，不和朋友的朋友谈话。
- 接口隔离原则：客户端不应依赖它不需要的接口。如果一个接口在实现时，部分方法由于冗余被客户端空实现，则应该将接口拆分，让实现类只需依赖自己需要的接口方法。
所有设计模式的应用都是为了程序能更好的满足这六大原则。
Go 学设计模式--合订本
这里把所有设计按照大类型分类，整理成一个设计模式学习的合订本，方便从全局角度学习设计模式。
|
设计模式合订本 |
||
|
建造型 |
单例模式 |
|
|
工厂模式 |
||
|
建造者模式 |
||
|
原型模式 |
||
|
结构型 |
代理模式 |
|
|
适配器模式 |
||
|
装饰模式 |
||
|
组合模式 |
||
|
外观模式 |
||
|
享元模式 |
||
|
桥接模式 |
||
|
行为型 |
观察者模式 |
|
|
模版模式 |
||
|
策略模式 |
||
|
职责链模式 |
||
|
状态模式 |
||
|
迭代器模式 |
||
|
访客模式 |
||
|
命令模式 |
||
|
解释器模式 |
||
|
中介者模式 |
||
最后
关于设计模式的学习和写作就暂告一个段落啦，大家可以收藏这篇文章，需要的时候拿出来再看看，多多实践，内化成自己的编程内功才是王道。
设计模式系列里我讲程序结构时，用了很多UML类图，实际上UML是软件设计里单独的一个领域系统的结构分析、流程分析、功能分析、架构分析都能用UML来做。
这里也预告一下今年计划要做的精品付费阅读内容-- 程序员的UML绘图课，如果你有写论文、软件需求规格书、系统招标书等需要把代码用人人都能理解的绘图表达出来的需求，都可以期待一下。
今天给文章开了赞赏，如果设计模式这个系列的文章有帮助到你，可以随意赞赏，也欢迎大家在评论区讨论起来，据说每个人都有一个喜欢重构代码的同事，说说大家为了写好程序都干过什么吧！
