如何不将指定地图的键集和值集混为一谈？

Question

Clojure 官方规范文档指出：

大多数用于指定结构的系统都将 键集（例如地图中的键，对象中的字段）与 这些键指定的值的规范。 IE。在这样的 接近地图的模式可能会说：a-key's type is x-type and :b-key 的类型是 y-type。这是僵硬的主要来源 冗余。

在这个 SO 问题中：clojure.spec human readable shape?

给出下面的例子：

(s/def ::car (s/keys :req [::tires ::chassis]))

(s/def ::tires (s/coll-of ::tire :count 4))

(s/def ::tire (s/or :goodyear ::goodyear}
                    :michelin ::michelin))

我的问题是：这怎么不是很简单，也不是多余的？与此相反，什么是（在 Java 中？）僵化和冗余的例子？

在我看来，你仍然不能定义一辆有 6 个轮子的赛车，因为::tires 必须有 4 个元素。您也不能定义后轮是螺旋桨的浮动汽车。

从刚性和冗余的角度来看，上述示例与静态类型有何不同？这与使用包含四个 tire 实例的 tires 实例构建的 Java car 类有什么不同？

基本上，我认为我没有得到的是您通过告诉需要哪些键来指定地图。到现在为止还挺好。但是键是自己指定的，所以这些键指定的值也没有指定！？这里的事情如何“没有混淆”？

Answer 1

请稍等片刻，将软件开发视为一种实践。我们将在底部进行规范。

作为工程师，我们最重要的技能之一是在抽象中定义和思考的能力。

想想函数组合如何简化复杂软件的构建。它允许我们更广泛地思考正在发生的事情，从而简化了复杂函数的定义。这样做的一个很好的好处是，它还允许在编写类似但略有不同的复杂函数时重用组成较大函数的较小函数。

当然，您根本不需要 函数。您可以在一个函数中编写整个项目。然而，这是一个坏主意，主要是因为它将函数的意图与函数的规范混为一谈。

例如，函数make-car 调用build-engine、build-drivetrain、install-interior 等等。当然，您可以从其中获取代码并将它们粘贴到 make-car 中。但结果是你失去了抽象。除了make-car 代码本身之外，make-car 无法改进或更改。如何构建引擎的代码无法改进或重用于制造任何其他汽车。为什么？因为关于如何为 that 特定汽车规格构建 that 引擎的知识嵌入在 make-car 函数中。

因此，make-car 不应定义如何 制造发动机（或汽车的任何其他组件）；它只是指定了汽车的组成部分，以及它们如何协同工作。这些组件的细节不属于make-car中嵌入的工作知识。

现在应该清楚与规范的比较：

以类似的方式，规范允许您将实体定义为抽象。您能否将实体的知识嵌入规范/模式中？当然。您可以直接将各个组件的规范替换为实体定义本身吗？是的。但这样做时，您将实体与其组件的定义混为一谈。损失与上述相同：您失去了对实体的抽象，因为现在您必须更改实体的定义才能更改有关实体的详细信息它的组成部分；而且，您已经失去了为相似但不同的实体重用定义的能力。