作者ohmylove347 (米特巴尔)
看板Soft_Job
标题[讨论] FP正在杀死设计模式吗？
时间Tue Jun 25 11:02:11 2024
拿策略模式举例，因为正好在研究这个
http://i.imgur.com/UWc8gR6.jpg
Context 和 Strategy：组合关系，Context 持有 Strategy。
Strategy 和 ConcreteStrategyA/B：实现关系，ConcreteStrategyA 和 ConcreteStrategy
先简单定义，策略模式是"将相同类型可互相替换的操作封装成独立策略，达到在运行时动态替换"的一种设计模式
Java要实现的话，比较普遍的作法：
1. 定义策略Class or Interface
2. 实现具体策略类
3. 创建上下文类管理策略的设定与使用
但是使用一些天生自带FP特性的语言(现在用Kotlin
发现策略模式好像根本不需要
最简单的方法是直接利用高阶函数，把需要的操作当参数传进去用
连定义Interface都省了，只要函数签名相同都行
如果要限制操作种类
只要写个枚举类整理一下全部的操作就好，也不用额外的策略类跟上下文
还能隐藏策略的具体实现只让选择本身可见
看了看，好像策略模式用不太到？
是不是高阶函数太好用了
只要关於动态行为的时候
用高阶函数加个函数参数搞定
FP是不是某种程度上杀死设计模式了？
-----
Sent from JPTT on my Google Pixel 7 Pro.
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.136.159.79 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1719284536.A.657.html
※ 编辑: ohmylove347 (114.136.159.79 台湾), 06/25/2024 11:05:01
※ 编辑: ohmylove347 (114.136.159.79 台湾), 06/25/2024 11:06:15
1F：推 sw12: 设计模式，是从OO长出来的.... 06/25 11:12
2F：→ sw12: 跟杀死没关系。就不适用 06/25 11:12
※ 编辑: ohmylove347 (114.136.159.79 台湾), 06/25/2024 11:14:51
3F：→ NDark: OO就跟Scrum是一种理所当然 专注在他们想解决的课题才合理 06/25 11:14
4F：推 papa510: 是的 很多情境下可以设计更简单，传参数就好了 06/25 11:53
5F：→ w0005151: 你的例子还是策略模式啊，只是interface省了而已 06/25 13:22
6F：→ w0005151: FP不是只是first call function就是FP 06/25 13:22
7F：→ w0005151: *first class function 06/25 13:23
8F：推 brucetu: 那你不就只有杀死策略模式-.- 举个例子 singleton 呢？观 06/25 13:52
9F：→ brucetu: 察者 / 装饰器 / 发布订阅等等常用的模式呢？你把这些拿 06/25 13:52
10F：→ brucetu: 出来看再看看 FP 再学一下 javascript 这种超高自由度的 06/25 13:52
11F：→ brucetu: 语言，再重新下结论不迟 06/25 13:52
12F：→ brucetu: 即使是 JS 也会用到各种设计模式 06/25 13:53
13F：→ brucetu: 高内聚低耦合可测试才是重点，OO或FP不重要也可以混用 06/25 14:00
14F：推 wei115: 设计模式也要看语言八 有些设计模式是在补语法的问题 06/25 14:37
15F：→ wei115: 有语言特性支援，很多技巧可以省略 06/25 14:38
16F：推 MoonCode: 还要配上好的型别系统才能用的爽 06/25 14:39
17F：推 black2575: 杀死Pattern 不是好事吗 如果今天语言能解决对应问题 06/25 15:30
18F：→ black2575: 我不就不需要另外尻这些Pattern了 06/25 15:30
19F：→ Lordaeron: 台湾的另一个有趣的现象，就是大家的案子，基本上没几 06/25 15:50
20F：→ Lordaeron: 个"物件"会重用的，但大家就是天天design pattern. 06/25 15:50
21F：推 NDark: 那就是overdesign 06/25 16:05
22F：→ NDark: 但也跟案子的型态很有关 06/25 16:06
23F：→ NDark: 周期太短 产品风险太高无法回避的 线上正常的 要减少重构 06/25 16:06
24F：→ NDark: 新code可以用更好的方法去实现 但不要回头为了重用而重改 06/25 16:07
25F：→ NDark: 换言之 不是重构程式码 而是重构人的思维模式 06/25 16:07
26F：推 mercurycgt68: 前公司架构师：我入行这几年 06/25 16:49
27F：→ mercurycgt68: 从来不需要用什麽design pattern 06/25 16:49
28F：推 NDark: 不用的原因有可能已经是无招胜有招 06/25 16:50
29F：→ NDark: 因为对工作於设计模式出现之前的也是会有方法解决问题 06/25 16:51
30F：→ NDark: 设计模式只是把那些方法归类取名 06/25 16:51
31F：→ NDark: 所以 不用 指得不是不用方法 而是那时还不叫设计模式 06/25 16:51
32F：推 abccbaandy: 推19F，一堆整个开发周期都只有一个impl的在那边定 06/25 16:53
33F：→ abccbaandy: interface超87，不定还会森77说你开发习惯不好XD 06/25 16:53
34F：→ NDark: 这就是overdesign 没有扩充需求应是搞需求出来 06/25 16:57
35F：→ NDark: 设计是为了需求服务 这点很多人没搞懂 06/25 16:57
36F：→ NDark: 在需求很不明确或是可以预期跳跃的时候 要尽量少系统与架构 06/25 16:58
37F：推 k798976869: FP就是一种可以一直串的设计模式啊 要尽量写pure func 06/25 18:41
38F：→ k798976869: tion 06/25 18:41
39F：推 wulouise: 原来fp是说functional programming.. DP就是有需要才用 06/25 18:47
40F：→ recorriendo: 你说的模式本身就可以当作是FP和OOP的结合 06/25 19:16
41F：→ recorriendo: 基本的OOP 每个物件就可以视为带有一组"背景资料" 06/25 19:18
42F：→ recorriendo: 但方法函式不能"动态扩充" 06/25 19:18
43F：→ recorriendo: 而纯FP则是没有context的概念 你的模式等於把两方 06/25 19:20
44F：→ recorriendo: 加上各自缺少的部分 06/25 19:20
45F：→ recorriendo: 有没有必要当然是取决於现实需求 06/25 19:21
46F：→ KY1998: 你应该多看原始码，其实用不少，你同事会不会又是另一回事 06/25 20:50
47F：推 blackdiz: 这支影片的观点满类似的，可以参考看看 06/25 21:29
49F：推 foxbrush: *定义Interface都省了，只要函数签名相同都行* <= 你自 06/25 21:56
50F：→ foxbrush: 己都说了函数签名仍要相同，不过是语言特性省去写Interf 06/25 21:56
51F：→ foxbrush: ace，还是一样的pattern 06/25 21:56
52F：→ superpandal: 设计模式就是oop如Java 因为语言限制而产生的经验法 06/25 23:32
53F：→ superpandal: 则 即便你不知道什麽叫作策略模式 你依照限制依究能 06/25 23:34
54F：→ superpandal: 产生出来而不用看书 只有这类的语言才讲究这种东西 06/25 23:36
55F：→ superpandal: fp或动态语言很爽的其实可以不用管这种东西 而程式码 06/25 23:40
56F：→ superpandal: 品质最终还是取决於个人的心态和目的 06/25 23:41
57F：→ superpandal: 记得在对岸论坛看过某句话很有道理 忘记在哪 大概意 06/26 00:05
58F：→ superpandal: 思是人们发明新概念与观点方式用来解决问题 然而该事 06/26 00:07
59F：→ superpandal: 物会用某种型式反过来束缚你 06/26 00:08
60F：→ superpandal: 不过意思差不多可以类比成独孤九剑和一般剑法 06/26 00:10
61F：推 vi000246: 看情况吧 如果你是要写一个plugin给别人用 定interface 06/26 00:31
62F：→ vi000246: 就满重要的 就好像电线之於插座 用电线可以接上任何电 06/26 00:32
63F：→ vi000246: 器 但要是220v接到100v呢 这时就需要靠interface来限定 06/26 00:32
64F：→ vi000246: 接口长怎样 06/26 00:32
65F：→ vi000246: 这世界的电器百百种 有个既成的规格可以让电器开发商 06/26 00:34
66F：→ vi000246: 不需烦恼接口的事 当然小专案就不需要考虑这些了 06/26 00:35
67F：→ vi000246: 能动比较重要 06/26 00:35
68F：推 abccbaandy: 楼上这种教科书般的例子实际很少有吧，真要说手机快充 06/26 00:49
69F：→ abccbaandy: 不也搞了一堆特规... 06/26 00:49
70F：→ DrTech: 台湾没什麽人在写十万行起跳的程式码framework，不用开发f 06/26 02:16
71F：→ DrTech: ramework给百人，千人，万人用。当然觉得不需要设计模式。 06/26 02:16
72F：→ DrTech: 你写的程式顶多几千行，顶多2-3个人会看第二次，就很了不 06/26 02:16
73F：→ DrTech: 起了。当然不需要设计模式也能做得更好。 06/26 02:16
74F：→ DrTech: 设计模式的圣经书书名都说了：Elements of Reusable Objec 06/26 02:21
75F：→ DrTech: t-Oriented Software 06/26 02:21
76F：→ DrTech: 因为你写的，不需要一直给别人重复使用，当然不需要设计模 06/26 02:22
77F：→ DrTech: 式。 06/26 02:22
78F：→ brucetu: 让我用绿豆糕的角度回答这个问题，我觉得设计模式是许多 06/26 08:28
79F：→ brucetu: 种可用来描述演算法的常用模式，一个问题可以有多种不同 06/26 08:28
80F：→ brucetu: 的解，你的解题思路不同就会选用不同的模式，倒不一定是 06/26 08:28
81F：→ brucetu: 为了重用程式码。就像一个问题可以回圈解也可以递回解， 06/26 08:28
82F：→ brucetu: 也还可以用状态机解。套用模式的好处是别人容易看懂你在 06/26 08:29
83F：→ brucetu: 做什麽 06/26 08:29
84F：→ recorriendo: 没有完美的语言 模式也只是前人在补强功能的各种方 06/26 08:36
85F：→ recorriendo: 式中归纳出来供人借鉴的 06/26 08:36
86F：→ recorriendo: 这些被归纳出来的模式 就是有经过时间证明其价值 06/26 08:36
87F：→ recorriendo: 要不照模式 当然可以 不过多数时候是几个月後就会 06/26 08:36
88F：→ recorriendo: 後悔当初自以为的天才hack 06/26 08:36
89F：→ superpandal: 十万行的多数是屎山 最少行数最简短的实现一样的功能 06/26 09:25
90F：→ superpandal: 才是好的 物件导向也只是其中一种方式 06/26 09:27
91F：→ superpandal: 这就是套路或者称作是定石搂 然而并不需要专门去学才 06/26 09:32
92F：→ superpandal: 会了解 如上所说 这只是限制下的经验 看了这篇说实话 06/26 09:33
93F：嘘 WTS2accuracy: 什麽鬼逻辑...FP只是换个方式实作设计模式而已 06/26 09:34
94F：→ superpandal: 我也不知道什麽叫作策略模式 但我就写出一模一样的东 06/26 09:34
95F：→ superpandal: 西过 06/26 09:34
96F：→ superpandal: 要看语言本身特性 对很多语言来讲是可以跳过这环节的 06/26 09:36
97F：推 zxcasdjason1: 个人浅见是，设计模式像心法，OO, FP 则像外功。FP 06/26 11:38
98F：→ zxcasdjason1: 是否好用，还是要看你用的语言特性，像原po提到的J 06/26 11:38
99F：→ zxcasdjason1: S， class 只是语法糖，跟 java, c#, 本质就不同， 06/26 11:38
100F：→ zxcasdjason1: 对 JS 来说，用 function 更直觉。 自己工作上从 O 06/26 11:38
101F：→ zxcasdjason1: O 转 FP 一段时间， 相比 OO 来说，FP 设计上讲究 06/26 11:38
102F：→ zxcasdjason1: 状态皆来自参数，无副作用的函式测试好写，也好维 06/26 11:38
103F：→ zxcasdjason1: 护。 06/26 11:38
104F：推 wulouise: 咦原来十万就是很多了... 06/26 12:54
105F：→ ma721: 自己跟别人看好懂好维护就行 06/26 14:01
106F：→ KY1998: JS转TS时，generics应该会让你不太爽 06/26 14:19
107F：→ superpandal: 实际上设计模式还是外功 你整的再好也只是在上面玩耍 06/26 15:46
108F：→ superpandal: 能整到十万我怀疑它的品质以及可维护程式可控性 06/26 15:49
109F：→ angusyu: 怎麽可能取代策略模式…我一样用策略模式不会塞lambda 06/26 20:30
110F：推 Lipraxde: 写十万行 code... 有两种，一种是需要写十万行...另一 06/26 20:36
111F：→ Lipraxde: 种是写了十万行，就像 design pattern 一样，一种是需 06/26 20:36
112F：→ Lipraxde: 要用...另一种是用下去了 06/26 20:36
113F：→ viper9709: 台湾的软体生命周期太短+1 06/26 21:19
114F：→ peter98: design pattern常用的可以用，不常用的就别用，很多desig 06/26 22:55
115F：→ peter98: n pattern写到最後会让人无法trace code，如果只是个几万 06/26 22:56
116F：→ peter98: 行而已的专案就别全部硬要套design pattern了，常用的倒 06/26 22:56
117F：→ peter98: 是可以用，比如builder/factory/singleton/deco等 06/26 22:56
118F：→ peter98: 另外台湾的软体不是软体，板子换了软体重写，也不需要用 06/26 22:57
119F：→ peter98: design pattern，写code可以hardcode就好，速度快，出错 06/26 22:58
120F：→ peter98: 也没关系，反正出bug的时候，该软体可能都快结束生命了 06/26 22:58
121F：→ peter98: 反正出问题也不需要再修~ 何必搞design pattern? 06/26 22:58
122F：→ appleway: 不同的语言有不同的DP. Haskell有lens 但是Java不用 06/26 23:24
123F：推 CoNsTaR: FP 以外唯一支持 C++ TMP，C++20/23 加上 boost::mp11 06/27 01:34
124F：→ CoNsTaR: 根本 compile-time dependent type，几乎是想做什麽都可 06/27 01:34
125F：→ CoNsTaR: 以帮你 type check 06/27 01:34
126F：→ CoNsTaR: 传统设计模式相较之下就像是二维平面的小孩玩具一样帮 QQ 06/27 01:34
127F：→ Suleika: interface写好，设计想得很好，结果同类型新专案不拿去 06/27 17:10
128F：→ Suleika: 共用的场景太多了，写的让同事看得懂优先级可能高点 06/27 17:10
129F：推 ko27tye: 选择用什麽pattern之前 先考虑同事的程度吧 06/27 19:23
130F：→ Lipraxde: Builder 跟 factory 不是很让人喜欢...看到生搬硬套的 06/27 20:28
131F：→ Lipraxde: 用法就很讨厌 06/27 20:28
132F：推 jhjhs33504: 不需要帮印度人归纳的方法背书很多模式在OS,APP能找到 06/29 10:00
133F：推 legion87: 了解每个pattern的精神就好，很多程式码的语法精进的本 07/06 17:14
134F：→ legion87: 身就已经包含了一些设计模式的概念了 07/06 17:14
135F：→ legion87: 不是说一定要套用最原本的class diagram才叫设计模式 07/06 17:15
136F：→ legion87: Java的enum一出来，策略模式的写法都改变了，但精神上还 07/06 17:16
137F：→ legion87: 是策略模式 07/06 17:16
138F：推 dickgg: 其实 FP 历史是早於 OO 的，只是後来OO 比较红。比较像是 07/09 23:42
139F：→ dickgg: 纯的 FP 不好懂所以流行 OO + DP 07/09 23:42