user-interface - 功能风格的对象模型？

Question

以函数式风格实现对象模型是否切实可行？

OOP 似乎擅长的一个问题是描述对象模型。

例如，HTML DOM 是一个复杂的、有状态的野兽，它直接与 UI 交互，需要动态语言的可编程性。 OOP 特性往往以多种方式发挥作用:

成员访问限制使与不受信任的代码(例如 javascript)的交互变得安全

访问器函数和属性使绑定(bind)到 UI 更加方便

不必一直传递对象模型使方法更简单。

如果您通过 MVVM 投影模型，故事的 UI 方面可能会有点实际意义，但您仍然在内部不断地与状态角力。

我正在为这个项目在 F# 中工作，所以我可以轻松地求助于 OOP，但我很好奇在它变得不切实际之前我能插入它多远。是否有设计模式或任何东西？

Answer 1

有一个“正确”的答案有点哲学，但好吧我会咬一口。

在我看来，问题的出现是因为您认为 FP 和 OO 是并列的，但事实并非如此。 FP 和命令式编程是并列的，即使用表达式与使用语句。

部分问题在于 OO 缺乏明确的定义，无论如何，在我看来。为了支持这一点，我要指出 Alan Kay，他说“实际上我创造了“面向对象”这个术语，我可以告诉你我并没有想到 C++。”但我们认为大多数语言都是面向对象的，即 java/C#在 C++ 之后比 smalltalk 花费更多。

OO C++/java/C# 风格确实给我们提供了一种很好的方式来将我们的代码组织到模型中，创建包含向它们添加属性的数据等。这些实际上都不是功能性的，并且可以很好地用于函数式编程。

正如您所指出的，许多 C++/java/C# 往往是有状态的，但它们并非必须如此，java 和 C# 都具有基本类型，例如它们的字符串类是不可变的。确实，java 和 C# 并没有让创建不可变类变得容易，但只要付出一点努力，你就可以做到。

这将我们带到了不可变的适当之处？在我的设计中，通常从使所有内容不可变开始，因为这使事情更容易纠正，如果我发现这会导致性能问题，我会开始在关键路径上添加一些可变性。不变性永远不会起作用的一个地方是 GUI 控件，它通常包含太多不可变的状态。话虽如此，您可以使用不可变的“组合器”方法构建 GUI，然后由可变 gui 控件解释。这或多或少是 WebSharper 家伙所做的:http://www.intellifactory.com/products/wsp/Home.aspx

FP/OO 辩论的另一个重要资源是 Brain 的“函数式编程如何影响代码结构？” (这极大地影响了我对 FP/OO 的思考):http://lorgonblog.wordpress.com/2008/09/22/how-does-functional-programming-affect-the-structure-of-your-code/