为什么“功能与数据之间的紧密耦合”不好？

我在第40页的“ Clojure的喜悦 ”中找到了这句话。32岁，但上周晚饭时有人对我说了同样的话，我在其他地方也听说过：

[A]面向对象编程的缺点是函数和数据之间的紧密耦合。

我理解为什么不必要的耦合在应用程序中不好。我也很高兴地说，即使在面向对象的编程中，也应避免避免可变状态和继承。但是我看不到为什么在类上粘贴函数本质上是不好的。

我的意思是，向类添加功能似乎就像在Gmail中标记邮件，或将文件粘贴在文件夹中。这是一种组织技巧，可帮助您再次找到它。您选择一些条件，然后将类似的东西放在一起。在OOP之前，我们的程序几乎是文件中方法的一大包。我的意思是，您必须将函数放在某个地方。为什么不组织它们？

如果这是对类型的公开攻击，为什么他们不只是说将输入和输出的类型限制为一个函数是错误的？我不确定是否可以同意这一点，但是至少我对pro和con类型安全性论点很熟悉。在我看来，这似乎是一个主要的问题。

当然，有时人们会错误地将功能放在错误的类上。但是与其他错误相比，这似乎是一个很小的麻烦。

因此，Clojure具有名称空间。在OOP中将函数粘贴在类上与在Clojure中将函数粘贴在命名空间中有什么不同，为什么这么糟？请记住，类中的函数不一定只在该类的成员上运行。看一下java.lang.StringBuilder-它可以对任何引用类型进行操作，也可以通过自动装箱对任何类型进行操作。

PS此引用引用了一本书，但我没有读过：《Leda中的Multiparadigm编程》：Timothy Budd，1995年。

从理论上讲，松散的功能数据耦合使添加更多功能来处理相同数据变得更加容易。不利的一面是，很难更改数据结构本身，这就是为什么在实践中，精心设计的功能代码和精心设计的OOP代码具有非常相似的耦合级别。

以有向无环图（DAG）为例的数据结构。在函数式编程中，您仍然需要一些抽象以避免重复自己，因此您将要制作一个具有以下功能的模块：添加和删除节点和边，找到给定节点可到达的节点，创建拓扑排序等。即使编译器不强制执行，它们也有效地紧密耦合到数据。您可以通过困难的方式添加节点，但是为什么要这样做呢？一个模块内的内聚性阻止了整个系统的紧密耦合。

相反，在OOP方面，除基本DAG操作之外的任何功能都将在单独的“视图”类中完成，并将DAG对象作为参数传递。添加对DAG数据进行操作的任意数量的视图，创建与功能程序中相同级别的功能数据解耦，就很容易。编译器不会阻止您将所有东西都塞进一堂课，但是您的同事会。

更改编程范例不会更改抽象，内聚和耦合的最佳实践，而只会更改编译器帮助您实施的实践。在函数式编程中，当您需要函数数据耦合时，它是由先生们而不是编译器同意执行的。在OOP中，模型视图分离是由先生们而不是编译器同意执行的。

如果您还不了解它，那就可以理解一下：面向对象和闭包的概念是同一枚硬币的两个方面。也就是说，什么是封闭？它从周围的作用域中获取变量或数据，并在函数内部或从面向对象的角度绑定到变量或数据，例如，当您将某些东西传递给构造函数时，您实际上会做同样的事情，以便以后可以使用该实例的成员函数中的一条数据。但是，从周围范围中拿走东西并不是一件好事-周围范围越大，这样做越有害（尽管从实用上讲，完成工作通常需要一些邪恶）。全局变量的使用将这一点推到了极致，程序中的函数在程序范围内使用变量-确实非常邪恶。有关于全局变量为何有害的其他地方的很好描述。

如果您遵循OO技术，那么您基本上已经接受了程序中的每个模块都会有一定程度的邪恶。如果您采用功能性的方法进行编程，那么您将追求一种理想的目标，即程序中的任何模块都不会包含闭包，尽管您可能仍然有闭包，但它比OO少得多。

那就是OO的缺点-它鼓励这种邪恶的做法，即通过使闭包成为标准（一种打破常规的编程理论），将数据耦合到功能上。

唯一的好处是，如果您知道要使用很多闭包作为开始，那么OO至少为您提供了一个思想框架来帮助组织这种方法，以便普通程序员可以理解它。特别是被关闭的变量在构造函数中是显式的，而不是在函数闭包中隐式地采用。使用很多闭包的功能程序通常比等效的OO程序更隐秘，尽管不一定会不太优雅：)

关于类型耦合：

对象中内置的用于该对象的函数不能在其他类型的对象上使用。

在Haskell中，您可以编写针对类型类使用的函数-因此，给定函数可以处理许多不同类型的对象，只要它是函数可以使用的给定类的类型即可。

独立的函数可以实现这样的去耦，当您专注于编写可在A型内部工作的函数时，这种解耦是不会实现的，因为如果您没有A型实例，那么即使您使用该函数，也无法使用它们否则应足够通用以用于B型实例或C型实例。

在Java和类似的OOP版本中，不能从其他模块中添加实例方法（与自由函数或扩展方法不同）。

当您考虑只能由实例方法实现的接口时，这将成为更多的限制。您不能在不同的模块中定义接口和类，然后使用第三个模块中的代码将它们绑定在一起。像Haskell的类型类这样的更灵活的方法应该能够做到这一点。

面向对象从根本上讲是关于过程数据抽象的（如果除去副作用是正交的问题，则是功能数据抽象）。从某种意义上说，Lambda Calculus是最古老，最纯净的面向对象语言，因为它仅提供功能数据抽象（因为它除了函数外没有任何构造）。

只有单个对象的操作才能检查该对象的数据表示。甚至同一类型的其他对象也无法做到这一点。（这是面向对象的数据抽象和抽象数据类型之间的主要区别：使用ADT，相同类型的对象可以检查彼此的数据表示形式，只有其他类型的对象的表示形式被隐藏。）

这意味着相同类型的几个对象可能具有不同的数据表示形式。即使是同一对象，在不同时间也可能具有不同的数据表示形式。（例如，在Scala中，Maps和Sets根据元素的数量在数组和哈希树之间切换，因为对于非常小的数字，由于常量因数非常小，所以数组中的线性搜索比对搜索树中的对数搜索快。 ）

从对象的外部，您不应该，也不知道其数据表示形式。这与紧密耦合相反。

数据和函数之间的紧密耦合是不好的，因为您希望能够彼此独立地进行更改，而紧密耦合则使此操作变得很困难，因为您无法在不了解另一种且可能无法更改另一种的情况下进行更改。

您希望向功能提供的不同数据不需要对功能进行任何更改，并且类似地，您希望能够对功能进行更改而无需更改正在运行的数据以支持那些功能更改。