从我（有限地）接触函数式编程语言（例如Clojure）开始，似乎数据封装的作用不那么重要。通常，各种本机类型（例如地图或集合）是代表对象的首选数据。此外，该数据通常是不可变的。
例如，这是Clojure的成名人物里奇·希基（Rich Hickey）在接受此事采访时最著名的名言之一：
Fogus：遵循了这个想法，Clojure并未对其类型进行数据隐藏封装，这一事实使某些人感到惊讶。您为什么决定放弃数据隐藏？
Hickey：让我们清楚一点，Clojure强烈强调对抽象的编程。但是在某个时候，某人将需要访问数据。而且，如果您有“私有”的概念，则需要相应的特权和信任的概念。这就增加了很多复杂性和很小的价值，在系统中产生了僵化，并常常迫使事物生活在不应有的地方。这是将简单信息放入类时发生的其他损失的补充。在某种程度上，数据是不可变的，提供访问的危害很小，除了有人可能会依赖可能发生变化的事物之外。好吧，好吧，人们在现实生活中一直如此，当事情发生变化时，他们就会适应。如果他们是理性的，他们知道，当他们基于可能会改变的事物做出决定时，将来可能需要适应。因此，这是一项风险管理决策，我认为程序员应该可以自由做出。如果人们不希望对抽象编程，也不愿意与实现细节相结合，那么他们永远都不会成为优秀的程序员。
来自面向对象的世界，这似乎使我多年来学到的一些基本原则变得复杂。其中包括信息隐藏，德米特定律和统一访问原则等。封装的共同点是使我们能够为其他人定义API，让他们知道应该和不应该接触的内容。从本质上讲，创建一个合同，允许某些代码的维护者自由地进行更改和重构，而不必担心它将如何在用户代码中引入错误（开放/封闭原则）。它还为其他程序员提供了一个干净，精心设计的界面，以使他们知道可以使用哪些工具来获取或建立该数据。
当允许直接访问数据时，该API合同被破坏，所有这些封装好处似乎都消失了。同样，严格不变的数据似乎在遍历特定于域的结构（对象，结构，记录）时，在表示状态和可以对该状态执行的操作的意义上要有用得多。
当代码库的大小变得巨大而需要定义API且许多开发人员参与处理系统的特定部分时，功能代码库如何解决似乎出现的这些问题？是否存在这种情况的示例，以说明在这些类型的代码库中如何处理此情况？
Also, strictly immutable data seems to make passing around domain-specific structures (objects, structs, records) much less useful in the sense of representing a state and the set of actions that can be performed on that state.并不是的。唯一更改的是更改最终出现在新对象上。在代码推理方面，这是一个巨大的胜利。传递可变对象意味着必须跟踪谁可能对其进行变异，这个问题随着代码的大小而扩大。