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


当前回答

正如其他人所说,函数式编程有特定的模式。我认为摆脱设计模式的问题与其说是转换到功能的问题,不如说是语言特性的问题。

看看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.

这就是模式和语言试图做的,让我们更简洁地表达我们的意图。思想的单位越丰富,你能表达的思想就越复杂。从系统架构到琐碎小事,在不同的范围内拥有丰富的、共享的词汇,可以让我们进行更明智的对话,并思考我们应该做什么。

作为个体,我们也可以学习。这就是练习的意义所在。我们每个人都能理解和使用我们自己永远无法想到的东西。语言、框架、库、模式、习语等等都在共享知识财富中占有一席之地。

函数式编程消除了对面向对象设计模式的需求这一说法是否属实?

函数式编程与面向对象编程不同。面向对象的设计模式不适用于函数式编程。取而代之的是函数式编程设计模式。

对于函数式编程,您不需要阅读面向对象设计模式书籍;你会读到其他关于FP设计模式的书籍。

语言无关的

不完全。对于面向对象语言,只有语言不可知。这种设计模式根本不适用于过程式语言。它们在关系数据库设计上下文中几乎没有意义。它们不适用于设计电子表格。

一个典型的OOP设计模式和它的功能对等物?

上述情况不应该存在。这就像要求将一段过程代码重写为OO代码。嗯……如果我将原始的Fortran(或C)翻译成Java,我所做的只是翻译它。如果我完全将其重写为面向对象范式,它将不再看起来像原始的Fortran或C语言——它将无法识别。

从面向对象设计到功能设计没有简单的映射。他们看问题的方式完全不同。

函数式编程(像所有编程风格一样)具有设计模式。关系数据库有设计模式,OO有设计模式,过程式编程有设计模式。任何事物都有设计模式,甚至是建筑物的结构。

设计模式——作为一个概念——是一种永恒的构建方式,与技术或问题领域无关。但是,特定的设计模式适用于特定的问题领域和技术。

每个人只要仔细思考自己在做什么,就会发现设计模式。

讨论这个问题时不能不提到类型系统。

函数式编程的主要特征包括函数作为第一类值、curry化、不可变值等。在我看来,OO设计模式是否接近这些特性并不明显。

这是因为这些特性不能解决OOP所解决的问题……它们是命令式编程的替代品。面向对象的FP答案在于ML和Haskell的类型系统……特别是和类型、抽象数据类型、ML模块和Haskell类型类。

当然,仍然有一些设计模式是FP语言无法解决的。FP与单例的等价是什么?(暂时不考虑单例对象通常是一种糟糕的模式)

类型类做的第一件事是消除对单例对象的需求。

你可以浏览这23个名单,然后再剔除更多,但我现在没有时间。

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

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

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

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

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