分析 Java/OOP 中类型的基数答案

【问题标题】：Analyzing cardinality of types in Java/OOP [closed]分析 Java/OOP 中类型的基数
【发布时间】：2019-06-29 01:45:07
【问题描述】：

在 Haskell、Purescript 和 Elm 等语言中，将类型视为集合是很强大的，如 here 所述。此工具可帮助您选择最适合您的问题的数据结构。它还允许您分析有多少种不可能的状态。

是否有可能将这个想法转移到过程 OOP 语言（如 Java）中，以分析不可能的状态是否不可能？如果是这样，那会是什么样子？

编辑：类型的基数为我们提供了一个类型可以表示的可能值的数量。在 FP 中，好的做法是根据数据对类型进行建模。通过计算基数，我们可以检查我们的程序是否有可能表示无效数据。如果数据结构的基数高于它应该保持的可能数据/状态的数量，则数据结构允许我们表示无效数据。

将此与 OOP 进行对比。在 OOP 中，我们不是在类型之后建模，而是在包含代表现实世界的属性和方法的对象之后建模。在 OOP 中是否有类似的方法可以分析对象的可能实例数量以检查该对象是否可以包含无效数据？我怀疑对象可能过于笼统，无法进行此类分析。

【问题讨论】：

就打字而言，一个类是一个（包装一个）产品类型，组成类型是类属性的类型。但是，除非您大量使用枚举类型，否则基数不会对您有太大帮助。像 int 和 string 这样的内置类型具有无限的基数（无论如何，有效；如果您使用这种技术，知道 int 的基数约为 40 亿不会非常有用。）

标签： java oop haskell functional-programming type-theory

【解决方案1】：

您可以将这些概念翻译成 OOP 语言，例如（我想）Java 或 C#。有些概念的翻译很冗长，但我涵盖了其中一些here。

产品类型只是您的普通Value Objects。 Sum 类型更棘手。

考虑the page linked to in the OP 中的Height 类型。你可以像这样在 C# 中Church encode它：

public interface IHeight
{
    T Match<T>(Func<int, T> inches, Func<float, T> meters);
}

这也需要两个实现这个接口的类。

原来 sum 类型的 Church 编码是equivalent to the Visitor design pattern，所以你也可以将 Height sum 类型定义为 Visitor：

public interface IHeight
{
    T Accept<T>(IHeightVisitor<T> visitor);
}

IHeightVisitor<T> 看起来像这样：

public interface IHeightVisitor<T>
{
    T VisitInches(int inches);

    T VisitMeters(float meters);
}

IHeight 的实现之一应该是这个：

public sealed class Inches : IHeight
{
    private readonly int inches;

    public Inches(int inches)
    {
        this.inches = inches;
    }

    public T Accept<T>(IHeightVisitor<T> visitor)
    {
        return visitor.VisitInches(inches);
    }
}

您还需要另一个实现，Meters 类，但我将把它留作练习（提示：它看起来很像 Inches）。

需要明确的是，IHeight 接口之类的东西确实应该是一个实现细节。然而，在这里，我用它来“展示我的作品”。您可能应该封装实现，以便没有人对实现该接口产生有趣的想法。这里是an example of how you might do that with Either。

【讨论】：