代数数据类型可以解决什么问题？

公平的警告，我是函数编程的新手，所以我可能有很多错误的假设。

我一直在学习代数类型。许多功能语言似乎都有它们，它们在与模式匹配一​​起使用时非常有用。但是，他们实际上解决了什么问题？我可以像这样在C＃中实现一个看似（排序）的代数类型：

public abstract class Option { }
public class None : Option { }
public class Some<T> : Option
{
    public T Value { get; set; }
}

var result = GetSomeValue();
if(result is None)
{
}
else
{
}

但是我认为大多数人都同意这是面向对象编程的混蛋，您永远都不要这样做。那么函数式编程是否只是添加了一种更简洁的语法，从而使这种编程风格看起来不太那么粗拙？我还想念什么？

具有接口和继承的类提供了一个开放的世界：任何人都可以添加一种新的数据。对于给定的接口，可能存在在世界各地以不同文件，不同项目，不同公司实施该接口的类。它们使向数据结构中添加案例变得容易，但是由于接口的实现是分散的，因此很难向接口中添加新方法。接口公开后，基本上就冻结了。没有人知道所有可能的实现。

代数数据类型是双重的，它们是封闭的。所有数据案例都集中在一个地方，并且操作不仅可以详尽地列出变体，还鼓励他们这样做。因此，编写对代数数据类型进行操作的新函数很简单：只需编写该死的函数即可。作为回报，添加新的案例很复杂，因为您需要基本上遍历整个代码库并扩展each match。与接口的情况类似，在Rust标准库中，添加新变量是一项重大更改（对于公共类型）。

这是表达问题的两个方面。代数数据类型是对它们的不完全解决方案，但是OOP也是。两者都有优点，取决于存在多少个数据案例，这些案例更改的频率以及操作扩展或更改的频率。（这就是为什么许多现代语言同时提供这两种方法或类似方法的原因，或者直接寻求更强大，更复杂的机制来尝试同时包含这两种方法的原因。）

那么函数式编程是否只是添加了一种更简洁的语法，从而使这种编程风格看起来不太那么粗拙？

也许这是一种简化，但是可以。

我还想念什么？

让我们弄清楚什么是代数数据类型（总结“ 将您学习为Haskell”中的这一精妙链接）：

• 总和类型显示为“此值可以是A 或 B”。
• 一种产品类型，上面写着“此值既是A 又是B”。

您的示例仅适用于第一个示例。

您可能缺少的是，通过提供这两个基本操作，功能语言可让您构建其他所有内容。C＃在它们之上具有结构，类，枚举，泛型，以及一堆规则来控制这些事物的行为。

结合一些语法帮助，功能语言可以将操作分解为这两个路径，从而提供了一种简洁，简单而优雅的类型处理方法。

代数数据类型可以解决什么问题？

它们解决了与任何其他类型系统相同的问题：“在这里使用什么值合法？” -他们只是采取了不同的方法。

得知模式匹配不是使用Options的最惯用的方式，可能会让您感到惊讶。有关更多信息，请参见Scala选项的文档。我不确定为什么这么多FP教程会鼓励这种用法。

通常，您所缺少的是创建了许多功能来简化使用Option的功能。考虑一下Scala文档中的主要示例：

val name: Option[String] = request getParameter "name"
val upper = name map { _.trim } filter { _.length != 0 } map { _.toUpperCase }
println(upper getOrElse "")

注意如何map和filter让您在选项上链接操作，而不必在每个点都检查您是否有None。然后，最后使用getOrElse您指定默认值。您绝对不会做“粗暴”的事情，例如检查类型。所有不可避免的类型检查都在库内部进行。Haskell具有自己的一组类似功能，更不用说将对任何monad或functor起作用的大量功能。

其他代数数据类型具有它们自己的惯用方式，并且在大多数情况下，图腾柱上的模式匹配很低。同样，在创建自己的类型时，期望提供类似的功能来使用它们。