这是一个创建于 993 天前的主题，其中的信息可能已经有所发展或是发生改变。
从 1 月 6 号开始利用两个月的时间把 23 个设计模式都过了一遍，详细总结了其中的 12 个，都结合了前端实际开发中遇到的场景。
撸了个网站把总结放了上去，读起来会更方便，欢迎阅读，欢迎拍砖：
每个设计模式的原始定义其实很好理解，直接打开维基百科看看定义、看看代码十几分钟估计就能了解一个，最重要的地方在于实际开发场景中的到底有哪些例子。
这方面的话前端相关的例子很少很少，我自己的经验有限，非常欢迎大家在 github 给我提 issues，把大家应用过或者见过的设计模式写一下，一起学习，一起进步！
 |
1
murmur 2022-03-11 08:03:30 +08:00  1
设计模式学多了容易魔怔，就你那个装饰器，我写个函数 makeMilkTea({Peral: 1, coconut: 2})他不香么,
前端和后端不一样，前端是搭积木，我不希望搞出个 car->iron car->car with air condition 的奇葩功能 我需要的是 superCar({airCondition: true})，你不行我就换一个行的组件用 |
|
2
murmur 2022-03-11 08:08:29 +08:00
这里不得不说一下以前 jq-easyui 的设计，panel->window->dialog 的继承，都魔怔了
首先 panel 在现在前端，就是个纯 css 样式，没啥 js 功能 window 和 dialog 差了什么，不就差个按钮么，那做一个 slot ，当时没有 vue 我做成选项不行么 所以我需要这么正统的继承关系么?我需要的是$.dialog({title: false, buttons: false} |
 |
3
ericls 2022-03-11 08:18:04 +08:00 via iPhone
做事情要从问题出发 不能从答案出发
|
 |
4
gouflv 2022-03-11 08:24:29 +08:00 via iPhone
感谢分享
|
 |
5
37Y37 2022-03-11 08:28:51 +08:00 via Android
前端竟然有这么多设计模式？
|
 |
6
windliang OP @murmur 总结的时候是按两个例子来讲，makeMilkTea 的例子是为了理解设计模式，纯虚构，没什么用。另一个例子是实际开发中用到的
|
|
7
windliang OP @murmur 前端的组件继承确实很尴尬，毕竟 React 也推出了 hooks ，放弃了 class 。因为这个原因所以很多设计模式在前端根本用不上，总结里也提到了
|
|
8
murmur 2022-03-11 09:08:10 +08:00
|
|
9
windliang OP @ericls 是的，所以我都是尽可能的举了实际开发中遇到的例子，没有遇到的也没有去总结了。也希望大家遇到过的可以分享下
|
|
10
murmur 2022-03-11 09:10:49 +08:00
我的例子是针对"将传入的 option 进行装饰返回即可"这句话，也许实现跟你的想法不一样
毕竟 java 的装饰器可是装饰 Stream 那个类，前端很难想出这样的场景来 |
|
11
windliang OP @murmur 我理解的话，设计模式是结合场景来说的，Object.assign 就是提供的工具，就看怎么用了，如果符合装饰器的结构就行。因为 js 不需要 class 去生成对象，所以和原始的设计模式比起来确实有些牵强，但如果思想是一样的，我就归类为某个设计模式了。
|
|
12
windliang OP @murmur 因为 js 不需要类，就很尴尬，所以只能尽可能的理解设计模式本身的想法，然后在结合下 js 再应用
|
|
13
windliang OP @37Y37 理论上设计模式只是思想，和前端、后端没关系，但 js 是基于原型的面相对象，不是基于 class 的面向对象，网上也没有很多例子，所以我就总结了一下，希望抛砖引玉
|
 |
16
yaphets666 2022-03-11 09:30:57 +08:00
@ericls 模式和思想这两个词可以画等号的
|
 |
17
chiaf 2022-03-11 09:36:03 +08:00
|
|
18
ericls 2022-03-11 10:00:47 +08:00 via iPhone
@yaphets666 思想都套进模式了 那还有什么 innovation
|
|
19
windliang OP @chiaf 我的总结里也提到了，很不错的网站，但也主要是基于 class 的面向对象，很希望有对前端场景具体应用的设计模式的例子，所以我就又总结了一下，也希望更多人一起来
|
 |
20
JunC74 2022-03-11 10:31:13 +08:00
谢谢分享,设计模式是不错的方案,但是在很多情况下并不是最合适的.但一定是可行的.
|
|
21
yaphets666 2022-03-11 10:33:19 +08:00 via iPhone
@ericls 都是套路
|
|
22
JunC74 2022-03-11 10:35:00 +08:00
因为它们考虑的太多可扩展性了,很多时候我们并不需要太多这个.项目能活下来才最重要.
|
 |
23
RedBeanIce 2022-03-12 09:37:23 +08:00 via iPhone
冲啊，，我也是去年 1 月份到现在研究了一下设计模式，阶段性结束
|
 |
24
GiantHard 2022-03-14 14:20:21 +08:00
快速地浏览了一遍，楼主总结的挺好的。但是大多数的前端开发者都不习惯于使用 class ，所以我觉得你的一些例子中，完全可以去掉 class ，就比如”责任链模式“中的例子，把 handler 类换成几个纯函数，看起来会更让前端开发者熟悉一些。
在我看来，设计模式是一份指南，而不是规则。我相信，对于大部分开发者来说，了解设计模式有助于帮助自己写出好的代码。 |
Select Language