自从我去年开始学习f#和OCaml以来，我已经阅读了大量的文章，这些文章坚持认为设计模式(尤其是Java中的)是命令式语言中缺失特性的变通方法。我发现的一篇文章给出了相当有力的主张:
Most people I've met have read
the Design Patterns book by the Gang of
Four (GoF). Any self respecting programmer
will tell you that the book is
language agnostic and the patterns
apply to software engineering in
general, regardless of which language
you use. This is a noble claim.
Unfortunately it is far removed from
the truth.
Functional languages are extremely
expressive. In a functional language
one does not need design patterns
because the language is likely so high
level, you end up programming in
concepts that eliminate design
patterns all together.
函数式编程(FP)的主要特性包括函数作为一类值、curry化、不可变值等。在我看来，OO设计模式是否接近这些特性并不明显。
此外，在支持OOP的函数式语言(如f#和OCaml)中，使用这些语言的程序员显然会使用与其他OOP语言相同的设计模式。事实上，现在我每天都在使用f#和OCaml，我在这些语言中使用的模式与我在Java中使用的模式之间没有明显的区别。
函数式编程消除了对面向对象设计模式的需求这一说法是否属实?如果是这样的话，你能发布或链接到一个典型的OOP设计模式的例子及其功能对等物吗?
GoF设计模式是为Simula 67的后代面向对象语言(如Java和c++)编写的变通方法。
设计模式处理的大多数“弊病”是由以下原因引起的:
statically typed classes, which specify objects, but are not themselves objects;
restriction to single dispatch (only the leftmost argument is used to select a method, the remaining arguments are considered as static types only: if they have dynamic types, it's up to the method to sort that out with ad-hoc approaches);
distinction between regular function calls and object-oriented function calls, meaning that object-oriented functions cannot be passed as functional arguments where regular functions are expected and vice versa; and
distinction between "base types" and "class types".
在通用Lisp对象系统中，这些设计模式中没有一个不会消失，即使解决方案的结构本质上与相应的设计模式相同。(此外，该对象系统比GoF书早了十多年。Common Lisp在该书第一次出版的同一年成为了ANSI标准。)
就函数式编程而言，模式是否适用于它取决于给定的函数式编程语言是否具有某种对象系统，以及它是否模仿受益于模式的对象系统。这种类型的面向对象不能很好地与函数式编程相结合，因为状态的突变是最重要的。
构造和非突变访问与函数式编程兼容，因此与抽象访问或构造有关的模式可以适用:像工厂、Facade、代理、Decorator和访问者这样的模式。
另一方面，像状态和策略这样的行为模式可能不能直接应用于功能性OOP，因为状态突变是它们的核心。这并不意味着它们不适用;也许它们以某种方式与任何可用于模拟可变状态的技巧结合应用。
正如其他人所说，函数式编程有特定的模式。我认为摆脱设计模式的问题与其说是转换到功能的问题，不如说是语言特性的问题。
看看Scala是如何废除“单例模式”的:只需声明一个对象而不是一个类。
另一个特性，模式匹配，有助于避免笨重的访问者模式。对比如下:
Scala的模式匹配=类固醇访问者模式
Scala和f#一样，是OO-functional的融合。我不了解f#，但它可能有这些特性。
闭包是在函数式语言中出现的，但不需要被限制在函数式语言中。它们有助于使用委托模式。
还有一个观察结果。这段代码实现了一个模式:它是如此经典，如此基本，以至于我们通常不认为它是一个“模式”，但它确实是:
for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }
像Java和c#这样的命令式语言已经采用了本质上是一个函数结构来处理这个问题:“foreach”。
布莱恩关于语言和模式之间紧密联系的评论很中肯，
The missing part of this discussion is the concept of idiom. James O. Coplien's book, "Advanced C++" was a huge influence here. Long before he discovered Christopher Alexander and the Column Without a Name (and you can't talk sensibly about patterns without reading Alexander either), he talked about the importance of mastering idioms in truly learning a language. He used string copy in C as an example, while(*from++ = *to++); You can see this as a bandaid for a missing language feature (or library feature), but what really matters about it is that it's a larger unit of thought, or of expression, than any of its parts.
这就是模式和语言试图做的，让我们更简洁地表达我们的意图。思想的单位越丰富，你能表达的思想就越复杂。从系统架构到琐碎小事，在不同的范围内拥有丰富的、共享的词汇，可以让我们进行更明智的对话，并思考我们应该做什么。
作为个体，我们也可以学习。这就是练习的意义所在。我们每个人都能理解和使用我们自己永远无法想到的东西。语言、框架、库、模式、习语等等都在共享知识财富中占有一席之地。
