功能语言中的建筑思维

Dan*_*son 26 architecture f# functional-programming

我的相关问题框溢出了函数式编程问题.在审查了最相关的内容后,我仍然很想听到以下方面的意见:

您如何考虑使用函数式语言构建应用程序?

我不是在谈论语言特定的语法.我对概念组织范式(例如面向对象)感兴趣.

像许多人一样,我第一次接触封装和代码重用来自OO背景.由于我一直在研究不同的语言,函数式编程确实引起了我的注意.我开始意识到不变性,高阶函数等的好处.但是我仍然失去了对如何构建功能应​​用程序而不依赖于OO概念的感觉.实际上,我见过的许多功能性例子与意大利面条代码有更多共同之处,尽管我确信这是由于示例的简单性而不是功能方法中的任何固有缺陷.

这个问题是"什么时候应该使用函数式编程"的亲属,但我已经满足于自己的功能方法,尽管在某些领域有利有弊,但几乎可用于任何你想要的东西.我只是难以想象复杂应用程序的大图片组织.

Nor*_*sey 21

在20世纪70年代后期,Barbara Liskov和其他人开发了大量的"面向对象设计"技术,这些技术至今仍被广泛使用,并且在功能编程中不变.它们最容易应用于具有显式接口和实现的语言,这意味着标准ML(其中接口称为"签名",实现称为"结构"或"仿函数")或Objective Caml(其中接口称为"模块类型") "和实现被称为"模块").如果您更喜欢Scheme,那么由Matthew Flatt和Matthias Felleisen开发的"单元"语言已构建到PLT Scheme中,是表达大型函数的一种非常好的方式.

简单来说:

  • 围绕抽象类型(OO中的类,FP中的"抽象类型")以及对这些类型的操作来组织应用程序.

  • 使用封装机制(OO中的类,FP中的模块)来隐藏抽象类型的表示.

  • 构建应用程序,以便每个实现通过其接口间接依赖于其他实现.这样,您就可以限制构建或修改任何一个应用程序所需的代码量.

  • 去镇上!

主要区别在于,在编写函数式程序时,不要使用继承来重用实现.相反,您使用高阶函数,或者使用将其他模块作为参数的模块.

总结:在架构层面上,没有太大的区别,但是在使用函数式语言时,您可能需要更加努力地找到所需的封装机制.


S.L*_*ott 2

大部分整体设计模式是完全适用的:

关注点分离; 模型-控制-表示(在其所有变体中);分层架构;输入-处理-输出等

一旦将一个大问题分解为较小的问题,较小的问题就需要完成从源表示到目标表示的各种转换。

我发现输入-处理-输出模式和转换管道模式很有帮助。