两个月时间抽空从前端的角度总结了一下设计模式

[windliang]

从 1 月 6 号开始利用两个月的时间把 23 个设计模式都过了一遍，详细总结了其中的 12 个，都结合了前端实际开发中遇到的场景。

撸了个网站把总结放了上去，读起来会更方便，欢迎阅读，欢迎拍砖：

pattern.windliang.wang

每个设计模式的原始定义其实很好理解，直接打开维基百科看看定义、看看代码十几分钟估计就能了解一个，最重要的地方在于实际开发场景中的到底有哪些例子。

这方面的话前端相关的例子很少很少，我自己的经验有限，非常欢迎大家在 github 给我提 issues，把大家应用过或者见过的设计模式写一下，一起学习，一起进步！

[murmur]

设计模式学多了容易魔怔，就你那个装饰器，我写个函数 makeMilkTea({Peral: 1, coconut: 2})他不香么,

前端和后端不一样，前端是搭积木，我不希望搞出个 car->iron car->car with air condition 的奇葩功能

我需要的是 superCar({airCondition: true})，你不行我就换一个行的组件用

[murmur]

这里不得不说一下以前 jq-easyui 的设计，panel->window->dialog 的继承，都魔怔了

首先 panel 在现在前端，就是个纯 css 样式，没啥 js 功能

window 和 dialog 差了什么，不就差个按钮么，那做一个 slot ，当时没有 vue 我做成选项不行么

所以我需要这么正统的继承关系么?我需要的是$.dialog({title: false, buttons: false}

[ericls]

做事情要从问题出发 不能从答案出发

[gouflv]

感谢分享

[37Y37]

前端竟然有这么多设计模式？

[windliang]

@murmur 总结的时候是按两个例子来讲，makeMilkTea 的例子是为了理解设计模式，纯虚构，没什么用。另一个例子是实际开发中用到的

[windliang]

@murmur 前端的组件继承确实很尴尬，毕竟 React 也推出了 hooks ，放弃了 class 。因为这个原因所以很多设计模式在前端根本用不上，总结里也提到了

[murmur]

@windliang 那问题来了，就你的例子来说，Object.assign 或者库的 deep-extend 属于装饰器么

我认为过于牵强，尤其是 Object.assign 属于内置函数

[windliang]

@ericls 是的，所以我都是尽可能的举了实际开发中遇到的例子，没有遇到的也没有去总结了。也希望大家遇到过的可以分享下

[murmur]

我的例子是针对"将传入的 option 进行装饰返回即可"这句话，也许实现跟你的想法不一样

毕竟 java 的装饰器可是装饰 Stream 那个类，前端很难想出这样的场景来

[windliang]

@murmur 我理解的话，设计模式是结合场景来说的，Object.assign 就是提供的工具，就看怎么用了，如果符合装饰器的结构就行。因为 js 不需要 class 去生成对象，所以和原始的设计模式比起来确实有些牵强，但如果思想是一样的，我就归类为某个设计模式了。

[windliang]

@murmur 因为 js 不需要类，就很尴尬，所以只能尽可能的理解设计模式本身的想法，然后在结合下 js 再应用

[windliang]

@37Y37 理论上设计模式只是思想，和前端、后端没关系，但 js 是基于原型的面相对象，不是基于 class 的面向对象，网上也没有很多例子，所以我就总结了一下，希望抛砖引玉

[ericls]

@windliang 设计模式不是思想 只是对现有问题的有可能的解答的列举

[windliang]

@gouflv 发现问题一起交流！

[yaphets666]

@ericls 模式和思想这两个词可以画等号的

[chiaf]

[免费在线学习代码重构和设计模式]( https://refactoringguru.cn)

设计模式可以看看这个网站

[ericls]

@yaphets666 思想都套进模式了 那还有什么 innovation

[windliang]

@chiaf 我的总结里也提到了，很不错的网站，但也主要是基于 class 的面向对象，很希望有对前端场景具体应用的设计模式的例子，所以我就又总结了一下，也希望更多人一起来

[JunC74]

谢谢分享,设计模式是不错的方案,但是在很多情况下并不是最合适的.但一定是可行的.