拿策略模式举例，因为正好在研究这个
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是不是某种程度上杀死设计模式了？

设计模式，是从OO长出来的....跟杀死没关系。就不适用

OO就跟Scrum是一种理所当然 专注在他们想解决的课题才合理

是的 很多情境下可以设计更简单，传参数就好了

你的例子还是策略模式啊，只是interface省了而已FP不是只是first call function就是FP*first class function

那你不就只有杀死策略模式-.- 举个例子 singleton 呢？观察者 / 装饰器 / 发布订阅等等常用的模式呢？你把这些拿出来看再看看 FP 再学一下 javascript 这种超高自由度的语言，再重新下结论不迟即使是 JS 也会用到各种设计模式高内聚低耦合可测试才是重点，OO或FP不重要也可以混用

设计模式也要看语言八 有些设计模式是在补语法的问题有语言特性支援，很多技巧可以省略

还要配上好的型别系统才能用的爽

杀死Pattern 不是好事吗 如果今天语言能解决对应问题我不就不需要另外尻这些Pattern了

台湾的另一个有趣的现象，就是大家的案子，基本上没几个"物件"会重用的，但大家就是天天design pattern.

那就是overdesign但也跟案子的型态很有关周期太短 产品风险太高无法回避的 线上正常的 要减少重构新code可以用更好的方法去实现 但不要回头为了重用而重改换言之 不是重构程式码 而是重构人的思维模式

前公司架构师：我入行这几年从来不需要用什么design pattern

不用的原因有可能已经是无招胜有招因为对工作于设计模式出现之前的也是会有方法解决问题设计模式只是把那些方法归类取名所以 不用 指得不是不用方法 而是那时还不叫设计模式

推19F，一堆整个开发周期都只有一个impl的在那边定interface超87，不定还会森77说你开发习惯不好XD

这就是overdesign 没有扩充需求应是搞需求出来设计是为了需求服务 这点很多人没搞懂在需求很不明确或是可以预期跳跃的时候 要尽量少系统与架构

FP就是一种可以一直串的设计模式啊 要尽量写pure function

原来fp是说functional programming.. DP就是有需要才用

你说的模式本身就可以当作是FP和OOP的结合基本的OOP 每个物件就可以视为带有一组"背景资料"但方法函式不能"动态扩充"而纯FP则是没有context的概念 你的模式等于把两方加上各自缺少的部分有没有必要当然是取决于现实需求

你应该多看原始码，其实用不少，你同事会不会又是另一回事

这支影片的观点满类似的，可以参考看看https://youtu.be/srQt1NAHYC0

*定义Interface都省了，只要函数签名相同都行* <= 你自己都说了函数签名仍要相同，不过是语言特性省去写Interface，还是一样的pattern

设计模式就是oop如Java 因为语言限制而产生的经验法则 即便你不知道什么叫作策略模式 你依照限制依究能产生出来而不用看书 只有这类的语言才讲究这种东西fp或动态语言很爽的其实可以不用管这种东西 而程式码品质最终还是取决于个人的心态和目的记得在对岸论坛看过某句话很有道理 忘记在哪 大概意思是人们发明新概念与观点方式用来解决问题 然而该事物会用某种型式反过来束缚你不过意思差不多可以类比成独孤九剑和一般剑法

看情况吧 如果你是要写一个plugin给别人用 定interface就满重要的 就好像电线之于插座 用电线可以接上任何电器 但要是220v接到100v呢 这时就需要靠interface来限定接口长怎样这世界的电器百百种 有个既成的规格可以让电器开发商不需烦恼接口的事 当然小专案就不需要考虑这些了能动比较重要

楼上这种教科书般的例子实际很少有吧，真要说手机快充不也搞了一堆特规...

台湾没什么人在写十万行起跳的程式码framework，不用开发framework给百人，千人，万人用。当然觉得不需要设计模式。你写的程式顶多几千行，顶多2-3个人会看第二次，就很了不起了。当然不需要设计模式也能做得更好。设计模式的圣经书书名都说了：Elements of Reusable Object-Oriented Software因为你写的，不需要一直给别人重复使用，当然不需要设计模式。

让我用绿豆糕的角度回答这个问题，我觉得设计模式是许多种可用来描述算法的常用模式，一个问题可以有多种不同的解，你的解题思路不同就会选用不同的模式，倒不一定是为了重用程式码。就像一个问题可以循环解也可以递回解，也还可以用状态机解。套用模式的好处是别人容易看懂你在做什么

没有完美的语言 模式也只是前人在补强功能的各种方式中归纳出来供人借鉴的这些被归纳出来的模式 就是有经过时间证明其价值要不照模式 当然可以 不过多数时候是几个月后就会后悔当初自以为的天才hack

十万行的多数是屎山 最少行数最简短的实现一样的功能才是好的 物件导向也只是其中一种方式这就是套路或者称作是定石搂 然而并不需要专门去学才会了解 如上所说 这只是限制下的经验 看了这篇说实话

什么鬼逻辑...FP只是换个方式实作设计模式而已

我也不知道什么叫作策略模式 但我就写出一模一样的东西过要看语言本身特性 对很多语言来讲是可以跳过这环节的

个人浅见是，设计模式像心法，OO, FP 则像外功。FP是否好用，还是要看你用的语言特性，像原po提到的JS， class 只是语法糖，跟 java, c#, 本质就不同，对 JS 来说，用 function 更直觉。 自己工作上从 OO 转 FP 一段时间， 相比 OO 来说，FP 设计上讲究状态皆来自参数，无副作用的函式测试好写，也好维护。

咦原来十万就是很多了...

自己跟别人看好懂好维护就行

JS转TS时，generics应该会让你不太爽

实际上设计模式还是外功 你整的再好也只是在上面玩耍能整到十万我怀疑它的品质以及可维护程式可控性

怎么可能取代策略模式…我一样用策略模式不会塞lambda

写十万行 code... 有两种，一种是需要写十万行...另一种是写了十万行，就像 design pattern 一样，一种是需要用...另一种是用下去了

台湾的软件生命周期太短+1

design pattern常用的可以用，不常用的就别用，很多design pattern写到最后会让人无法trace code，如果只是个几万行而已的专案就别全部硬要套design pattern了，常用的倒是可以用，比如builder/factory/singleton/deco等另外台湾的软件不是软件，板子换了软件重写，也不需要用design pattern，写code可以hardcode就好，速度快，出错也没关系，反正出bug的时候，该软件可能都快结束生命了反正出问题也不需要再修~ 何必搞design pattern?

不同的语言有不同的DP. Haskell有lens 但是Java不用

FP 以外唯一支持 C++ TMP，C++20/23 加上 boost::mp11根本 compile-time dependent type，几乎是想做什么都可以帮你 type check传统设计模式相较之下就像是二维平面的小孩玩具一样帮 QQ

interface写好，设计想得很好，结果同类型新专案不拿去共用的场景太多了，写的让同事看得懂优先级可能高点

选择用什么pattern之前 先考虑同事的程度吧

Builder 跟 factory 不是很让人喜欢...看到生搬硬套的用法就很讨厌

不需要帮印度人归纳的方法背书很多模式在OS,APP能找到

了解每个pattern的精神就好，很多程式码的语法精进的本身就已经包含了一些设计模式的概念了不是说一定要套用最原本的class diagram才叫设计模式Java的enum一出来，策略模式的写法都改变了，但精神上还是策略模式

其实 FP 历史是早于 OO 的，只是后来OO 比较红。比较像是纯的 FP 不好懂所以流行 OO + DP