函数式语言中的架构思维 [英] Architectural Thinking in Functional Languages

问题描述

我的相关问题框充满了函数式编程问题.在查看了最相关的内容后，我仍然很想听听关于以下内容的意见:

My Related Questions box overfloweth with functional programming questions. Having reviewed the most relevant, I'm still curious to hear opinions on the following:

您如何看待用函数式语言构建应用程序?

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

I'm not talking about a language-specific grammar. I'm interested in conceptual organizational paradigms (e.g object orientation).

和许多人一样，我第一次接触封装和代码重用来自 OO 背景.由于我一直在研究不同的语言，因此函数式编程真的引起了我的注意.我开始掌握不变性、高阶函数等的好处.但是我仍然不知道如何在不依赖 OO 概念的情况下构建功能性应用程序.实际上，我见过的许多函数式示例与意大利面条式代码有更多的共同点，尽管我确信这是由于示例的简单性而不是函数式方法中的任何固有缺陷.

Like many, my first exposure to encapsulation and code reuse came from the OO background. As I've been researching different languages, functional programming really caught my eye. I'm beginning to grasp the benefits of immutability, higher-order functions, et cetera. But I still lose my sense of how to structure a functional application without falling back on OO concepts. Actually, many of the functional examples I've seen have more in common with spaghetti code, although I'm sure that's due to the simplicity of the examples rather than any inherent flaw in the functional approach.

这个问题类似于我什么时候应该使用函数式编程"，但我已经让自己满意了，尽管在某些领域有优点和缺点，但函数式方法几乎可以用于您想要的任何东西.我只是无法想象复杂应用的大局组织.

This question is kin to "when should I use functional programming," but I've already satisfied myself that the functional approach, despite pros and cons in certain domains, is usable for just about anything that you want. I just have trouble picturing the big-picture organization of a complex app.

推荐答案

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

In the late 1970s, Barbara Liskov and others developed a boatload of large-scale "object-oriented design" techniques which are still widely used today and which apply unchanged to functional programming. They are easiest to apply with a language that has explicit interfaces and implementations, which means Standard ML (where interfaces are called "signatures" and implementations are called "structures" or "functors") or Objective Caml (where interfaces are called "module types" and implementations are called "modules"). If you prefer Scheme then the "unit" language developed by Matthew Flatt and Matthias Felleisen is built into PLT Scheme and is a very good way of expressing large-scale functions.

简而言之:

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

• Organize your applications around abstract types (classes in OO, "abstract types" in FP) and the operations on those types.

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

Use encapsulation mechanisms (classes in OO, modules in FP) to hide the representations of your abstract types.

构建您的应用程序，以便每个实现通过它们的接口间接依赖于其他实现.通过这种方式，您可以限制构建或修改应用程序的任何一个部分所必须理解的代码量.

Structure your application so that each implementation depends on other implementations indirectly, through their interfaces. This way you limit the amount of code you have to understand to build or modify any one piece of your application.

去镇上！

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

The main difference is that when you're writing functional programs, you don't use inheritance to reuse implementations. Instead you use higher-order functions, or you use modules which take other modules as parameters.

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

Summary: at the architectural level, there's not a lot of difference, but when using functional languages you may need to hunt a little harder to find the encapsulation mechanisms that you need.

这篇关于函数式语言中的架构思维的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！