在以“功能”风格进行编程时，您是否在应用程序逻辑中编织了一个应用程序状态？

如何构建具有以下所有功能的系统：

1. 对不可变对象使用纯函数。
2. 只传递给它所需功能的数据，不再传递（即没有大的应用程序状态对象）
3. 避免对函数使用过多的参数。
4. 避免仅出于将参数打包和拆包到函数的目的而构造新对象的方法，只是避免将过多的参数传递给函数。如果我要将多个项目作为一个对象打包到一个函数中，则我希望该对象成为该数据的所有者，而不是临时构造的东西

在我看来，State monad违反了规则2，虽然它并不明显，因为它是通过monad编织而成的。

我觉得我需要以某种方式使用Lenses，但是关于非功能语言的文章很少。

背景

作为练习，我将现有的应用程序之一从面向对象的样式转换为功能样式。我要尝试做的第一件事是尽可能多地利用应用程序的内核。

我听到的一件事是，如何用一种纯函数式的语言来管理“状态”，而我相信这是由State monad完成的，从逻辑上讲，您称一个纯函数为“传递状态”。世界原样”，那么当函数返回时，它会返回给您变化后的世界状态。

为了说明这一点，您可以用一种纯粹的功能性方式来创建“ hello world”的方式有点像，您将程序的屏幕状态传递给程序，然后返回印有“ hello world”状态的屏幕状态。因此，从技术上讲，您要调用一个纯函数，并且没有副作用。

基于此，我遍历了我的应用程序，并且：1.首先将我的所有应用程序状态放入单个全局对象（GameState）中。2.其次，使GameState不可变。您无法更改。如果需要更改，则必须构造一个新的。我通过添加一个复制构造函数来做到这一点，该复制构造函数可以选择接受一个或多个已更改的字段。3.对于每个应用程序，我都将GameState作为参数传递。在函数内，在完成将要执行的操作后，它将创建一个新的GameState并返回它。

我如何拥有纯功能核心，以及外部的循环，该循环将GameState馈入应用程序的主工作流程循环。

我的问题：

现在，我的问题是，GameState有大约15个不同的不可变对象。最低级别的许多功能仅对其中一些对象起作用，例如保持得分。因此，假设我有一个计算得分的函数。今天，GameState传递给此函数，该函数通过使用新分数创建新的GameState来修改分数。

似乎有些错误。该功能不需要完整的GameState。它只需要Score对象。所以我更新了它以传递分数，并仅返回分数。

这似乎很有意义，所以我进一步介绍了其他功能。有些功能需要我从GameState传入2、3或4个参数，但是随着我一直在应用程序的外部核心中使用该模式，我传入了越来越多的应用程序状态。就像在工作流循环的顶部，我将调用一个方法，该方法将调用将调用一个方法的方法，依此类推，一直到计算分数为止。这意味着当前分数会通过所有这些层，只是因为最底层的函数将要计算分数。

所以现在我有了带有数十个参数的函数。我可以将这些参数放入一个对象中以减少参数数量，但是然后我希望该类成为状态应用程序状态的主位置，而不是在调用时简单地构造以避免重复传递的对象输入多个参数，然后解压缩它们。

所以现在我想知道我的问题是否是我的函数嵌套得太深了。这是因为希望具有较小的功能，所以我在一个功能变大时进行重构，然后将其拆分为多个较小的功能。但是这样做会产生更深的层次结构，即使外部函数未直接在这些对象上运行，传递给内部函数的所有内容也都必须传递给外部函数。

似乎只是在避免这种问题的过程中传入了GameState。但是我回到了原来的问题，即向函数传递比函数所需更多的信息。

我不确定是否有好的解决方案。这可能不是答案，但评论太久了。我在做类似的事情，以下技巧也有所帮助：

• GameState分层拆分，因此可以得到3-5个较小的部分，而不是15个。
• 让它实现接口，以便您的方法仅看到所需的部分。切勿退缩它们，因为您会对真实类型撒谎。
• 让部件也实现接口，以便您可以很好地控制所传递的内容。
• 使用参数对象，但要谨慎使用，并尝试将它们变成具有自己行为的真实对象。
• 有时传递的数量比需要的数量略多，而不是冗长的参数列表。

所以现在我想知道我的问题是否是我的函数嵌套得太深了。

我不这么认为。重构为小函数是正确的，但是也许您可以更好地对其进行重组。有时，这是不可能的，有时只需要第二（或第三）次就可以解决问题。

将您的设计与可变设计进行比较。是否存在因重写而变得更糟的情况？如果是这样，您是否不能像最初一样改善它们？

我无法与C＃对话，但是在Haskell中，您最终会传递整个状态。您可以显式地或使用State monad来执行此操作。要解决函数接收更多信息然后需要解决的问题，您可以做的一件事就是使用Has类型类。（如果您不熟悉，Haskell类型类有点像C＃接口。）对于状态的每个元素E，您可以定义一个类型类HasE，它需要一个函数getE来返回E的值。成为所有这些类型类的实例。然后，在您的实际函数中，您不需要显式地要求您使用State monad，而是需要您需要的元素具有Has类型类的任何monad；限制了函数可以使用其使用的monad的功能。有关此方法的更多信息，请参见Michael Snoyman的发表关于ReaderT设计模式的文章。

您可能会在C＃中复制类似的内容，具体取决于您定义传递状态的方式。如果你有类似的东西

public class MyState
{
    public int MyInt {get; set; }
    public string MyString {get; set; }
}

你可以定义接口IHasMyInt，并IHasMyString用方法GetMyInt和GetMyString分别。状态类如下所示：

public class MyState : IHasMyInt, IHasMyString
{
    public int MyInt {get; set; }
    public string MyString {get; set; }
    public double MyDouble {get; set; }

    public int GetMyInt () 
    {
        return MyInt;
    }

    public string GetMyString ()
    {
        return MyString;
    }

    public double GetMyDouble ()
    {
        return MyDouble;
    }
}

那么您的方法可能需要IHasMyInt，IHasMyString或整个MyState（如果适用）。

然后，您可以在函数定义上使用where约束，以便可以传递状态对象，但是状态对象只能到达string和int，不能到达double。

public static T DoSomething<T>(T state) where T : IHasMyString, IHasMyInt
{
    var s = state.GetMyString();
    var i = state.GetMyInt();
    return state;
}

我认为您最好了解Redux或Elm以及它们如何处理此问题。

基本上，您具有一个纯函数，它可以接收整个状态和用户执行的操作并返回新状态。

然后，该函数调用其他纯函数，每个纯函数处理状态的特定部分。根据操作的不同，这些功能中的许多功能可能什么也不做，只能返回原始状态不变。

要了解更多信息，请访问Elm Architecture或Redux.js.org。

我认为您想要做的是使用一种不应使用的面向对象语言，就好像它是一种纯函数式语言一样。并不是说OO语言就是邪恶。每种方法都有其优点，这就是为什么我们现在可以将OO样式与功能样式相结合，并且有机会使某些代码段具有功能，而其他代码仍保持面向对象，以便我们可以利用所有可重用性，继承性或多态性。幸运的是，我们不再局限于这两种方法，所以您为什么要限制自己使用其中一种方法？

回答您的问题：不，我不通过应用程序逻辑来编织任何特定的状态，而是使用适合当前用例的内容，并以最适当的方式应用可用的技术。

C＃尚未准备好（尚未）用作功能。