自从我去年开始学习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设计模式的例子及其功能对等物吗?


当前回答

有些模式更容易在支持FP的语言中实现。例如,策略可以很好地使用闭包来实现。然而,根据上下文,您可能更喜欢使用基于类的方法来实现策略,例如策略本身非常复杂和/或共享您想使用模板方法建模的结构。

根据我在多范式语言(Ruby)中开发的经验,FP实现在简单的情况下工作得很好,但是在上下文更复杂的情况下,基于GoF OOP的方法更适合。

FP方法并没有取代OOP方法,而是对其进行了补充。

其他回答

这是另一个讨论这个话题的链接:http://blog.ezyang.com/2010/05/design-patterns-in-haskel/

在他的博客文章中,Edward用Haskell描述了所有23种原始的GoF模式。

从本质上说,是的!

当一个模式绕过了缺失的特性(高阶函数、流处理……),最终促进了组合。 一遍又一遍地重写模式实现的需要本身可以被视为一种语言气味。

此外,这个页面(AreDesignPatternsMissingLanguageFeatures)提供了一个“模式/功能”转换表和一些不错的讨论,如果你愿意深入研究的话。

在函数式编程中,设计模式有不同的含义。事实上,大多数OOP设计模式在函数式编程中都是不必要的,因为有更高层次的抽象和hof用作构建块。

HOF的原理意味着函数可以作为 参数指向其他函数。函数可以返回值。

函数式编程不能取代设计模式。设计模式是不可替代的。

模式就是存在的;它们是随着时间的推移而出现的。GoF的书将其中一些正规化了。如果随着开发人员使用函数式编程语言而出现新的模式,那将是令人兴奋的事情,也许也会有关于它们的书籍。

OOP和FP有不同的目标。OOP旨在封装软件组件的复杂/可移动部分,FP旨在最小化软件组件的复杂性和依赖性。

然而,这两种范式并不一定是100%矛盾的,可以一起应用,从两个世界中获得好处。

即使使用像c#这样原生不支持函数式编程的语言,如果您理解FP原则,您也可以编写函数式代码。同样地,如果你理解OOP原则、模式和最佳实践,你也可以使用f#应用OOP原则。无论您使用何种编程语言,您都可以根据您试图解决的情况和问题做出正确的选择。