从 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 类换成几个纯函数,看起来会更让前端开发者熟悉一些。
在我看来,设计模式是一份指南,而不是规则。我相信,对于大部分开发者来说,了解设计模式有助于帮助自己写出好的代码。 |