《Easy 搞定 Go 语言设计模式》(Golang 设计模式，如此简单)
sanbenweiyang · 2022-10-08 11:08:52 +08:00 · 2739 次点击这是一个创建于 768 天前的主题，其中的信息可能已经有所发展或是发生改变。
一、在线教学视频
| 平台 | 链接 |
|---|---|
 |
https://www.bilibili.com/video/BV1Eg411m7rV |
 |
https://www.douyin.com/video/7146449608854523175 |
二、提纲
三、原创文章作品
四、源代码
Github： https://github.com/aceld/EasySJMS
Gitee： https://gitee.com/Aceld/EasySJMS
五、原创作品
 |
1
AKAUP 2022-10-08 11:19:52 +08:00
牛的，谢谢大佬
|
 |
2
chennqqi 2022-10-08 13:42:58 +08:00
大佬牛逼，点赞
|
 |
3
pastor 2022-10-08 13:57:39 +08:00  11
求设计模式党和面向对象中毒党放过 golang ，不要把你们的魔爪伸过来，求求你们了
阿里已经有一帮毒瘤 javaer 搞了一些 go 框架来毒害社区了，求求你们拿到 KPI 后就不要再继续这种行为了 孩子们会中毒的！ 坚决抵制！ |
 |
4
allgy 2022-10-08 16:35:28 +08:00
go 不需要设计模式，别来坑害新人了
|
 |
5
laolaowang 2022-10-08 17:44:38 +08:00
小猫画的不错
|
 |
6
xshell 2022-10-09 10:33:53 +08:00
八股文
|
 |
7
xianzhe 2022-10-09 12:16:41 +08:00 via Android
很奇怪为啥有些 goer 觉得 go 不需要设计模式
|
 |
9
sanbenweiyang OP @pastor 看到评论说 go 不需要设计模式，本来不想理的，但是看言语这么激进，想想还是得回复一下。 如果是因 go 的简洁而屏蔽设计模式，这太片面了。设计模式本是理论，是编程思想，是构建规模庞大的系统必备理论技能方法。和编程语言有何关系。 说 go 像 C 简单不需要设计模式的，可以看看 https://lwn.net/Articles/336224/ 这篇文档，这是 Linux 内核 用 C 语言总结出来的设计模式，真正写内核 C 语言的，不用面向对象的思想如何去迭代系统和代码。 写个 demo 级别的项目当然不需要设计模式了。当你的系统足够复杂，你再试试。 设计模式是理论，只不过是通过什么语言去学习而已，他并没有绑定什么编程语言，就算算法和数学一样。
|
|
10
pastor 2022-10-09 20:19:18 +08:00 3
@sanbenweiyang #9
我随便搜个帖子给你： https://www.infoq.cn/article/design-patterns-proposed-by-gof-20-years-ago 摘抄一段： ```text Gang of Four （简称 GOF ）似乎从一开始就将模式视为一种艺术 / 科学；在论著的最后一章（遗憾的是，读者们大多直接将其忽略），他们指出： 这本书的实际价值也许还值得商榷。毕竟它并没有提出任何前所未有的算法或者编程技术。它也没能给出任何严格的系统设计方法或者新的设计开发理论——它只是对现有设计成果的一种审视。大家当然可以将其视为一套不错的教程，但它显然无法为经验丰富的面向对象设计人员带来多少帮助。 但需要强调的是，实际情况在于：这本书中的模式设计理念尚未彻底完成。我在 DevelopMentor 上结识的一位朋友将设计模式称为“23 种指针使用方法”。好吧，似乎也有道理。 同样的，当管理层 / 高管团队将这本书甩给新手开发者并希望他们通过阅读实现技能“升级”时，结果也肯定会让他们深感失望。 ``` 你可以回头再看一下你举例的 linux 内核设计模式的站点：首先，这不是 linux 官方文档，而是其他人的总结；其次，这是针对 linux 内核而总结出来的，并不是 linux 内核根据 GOF 的设计模式进行的实践。 说道这里我不知道你有没有意识到自己对设计模式的理解存在的问题，如果没有，我进一步直接告诉你：你把设计模式与代码架构的先有鸡还是先有蛋的顺序搞反了（例如我上面解释了你对 linux 内核那个设计模式套过来做论据的错误）。 设计模式并不是只有 GOF 整理的这些，GOF 整理的这些也并不适合直接用于代码设计。设计模式的运用的最佳实践，应该是先有业务和代码，在实现以及发展的过程中，甚至是在日后重构的过程中，结合这个项目整理出项目本身对应的设计模式（实际上不只是整理设计模式，还应该整理项目的各种定义、规范等）。用既定的设计模式去设计架构、大型代码模块，只有一个大场景和很多小场景符合，大场景比如已经成熟的行业领域，比如传统企业级，已经多年深耕、架构、代码、模式成熟，所以当你从头再造一套，那些在这个领域已有的设计模式能帮助提高生产效率。小场景也是类似的道理，已有成熟的体系才行。而直接拿设计模式不分青红皂白往各种项目上套，八成制造更多屎山。 至于设计模式跟语言无关，那你可是更没理解到位了。比如单例，对于有全局变量或者全局静态变量的语言比如 c/cpp/go ，最简单的就是一个全局变量就搞定了，再多封装单例模式的 N 种写法也都是脱裤子放屁或者仅仅看上去接口 /方法的形式或许比变量更优雅而已（然而这种审美也是因人而异）。 总结起来，就是现有的代码实践，然后才有对应的整理出来的设计模式，如果使用这些模式去指导类似的业务或者逻辑的代码架构是存在一定合理性的，但生搬硬套是扯淡，尤其在这些年 IT 互联网行业高速发展、需求快速迭代的场景。这一点上，OOP 存在类似的问题，比如鸭嘴兽，比如快速迭代无法预测未来需求的快速变化，你在早起想在顶层设计阶段使用设计模式、OOP 做到日后的易扩展，简直就是痴人说梦。只有阶段性重构能真正让屎山改造成艺术品 |
|
11
pastor 2022-10-09 20:24:30 +08:00
我不知道你是不是刘丹冰老师本人，zinx 代码我扫过几眼，其他一些比如 cellnet 也扫过几眼，讲真，这些培训机构老师也好、专职做知识传播的专家也好，工程实践的代码质量优秀的比较少，还差些火候，但是普及传播基础知识对于年轻人还是够用的，我很支持。设计模式这种糟粕，你就别跟我杠了。好些人拿大道至简嘲讽 go ，但你是做 go 的，相信你不会像他们那么肤浅，自己多反思下什么是大道至简更好。
|
|
12
pastor 2022-10-09 20:31:40 +08:00
设计模式最初好像是被 GOF 那几人借鉴建筑领域搞的，建筑和软件虽然都是工程，也确实有很多可以借鉴之处，但是还有一个很大的区别，就是建筑领域的图纸方案是数学的物理的材料的定量的计算，更加规范，而且一经敲定很少需要在施工过程中再去大量更改需求和对应的方案的。软件则大不相同，从立项到完成，中间的产品需求和代码是分阶段输出，产品经理或者甲方改需求比 tm 40+男人尿尿还频，所以你根本没法像建筑领域那样图纸方案搞定后一铁锹干到底，而是得翻来覆去改代码改数据库改这个改那个的。
|
|
13
pastor 2022-10-09 20:37:17 +08:00
对付我这种人，最好的办法就是回去好好修炼内功，等 OP 真牛逼了、不再有这种错误的认知了、再出来传播的是牛逼的知识点的时候，我自然就拜服了，所以劝 OP 赶紧收了设计模式这神通吧
|
Select Language