oop - 我什么时候应该在 OOP 中创建对象？

Question

我曾尝试搜索此问题的答案，但很难用语言表达，而且许多问题要么是关于如何创建类，要么是关于如何做非常具体的事情。我需要更多的实用概述 - 我是自学成才的，我了解对象是什么(以及如何创建它们)，但我从未见过关于何时创建对象.

这听起来像是一个奇怪的问题，答案是“总是”，但我注意到我的 OOP 代码在某些时候往往开始看起来是程序化的。我如何结合我对这两种范例的理解，以便我可以编写结构良好的面向对象代码？在某些时候，主要函数或代码主体需要创建变量和实例化对象，然后执行诸如执行条件测试之类的操作，因此我正在努力弄清楚应该将什么作为对象放入代码中。

也许答案是我上面提到的所有这些点都应该由另一个对象封装。我不知道 - 从理解的角度来看，这是我努力前进的地方。

Answer 1

这可能不太适合 Stackoverflow，但这是一个非常好的问题，应该加以解决。您不小心遇到了编程中的一个常见问题:大多数“OOP”程序实际上并不是面向对象的。

OOP 的全部意义在于封装复杂性。 Alan Kay 最初将其设想为生物细胞，其中细胞的所有机器都与外界隔离，您只能通过进出信息与细胞进行交互。所以一个对象封装了一个完整的系统，它本身是由对象组成的，并且可以与其他对象组合成更大的对象。一切都将通过消息进行通信，没有人可以窥视其他人的内部。这就是面向对象编程的本意，许多写作仍然受到这种思想的影响。但是大多数自称为 OOP 的东西并没有这样做(以这种方式工作的东西今天通常被称为“Actor Model”，它可以是一种非常有效和健壮的编程方式，集中体现在像二郎)。

当今大多数 OOP 系统都认为对象是一个不那么有趣的东西(至少在我看来):它只是数据和可以对该数据进行操作的方法的组合。业界对于这是否是一个特别有用的结构存在很大争议(相对于将数据与方法分离的功能范式，或纯粹关注功能而非类的鸭子类型范式)。

但对于您在实践中提出的问题，我想说在大多数情况下我们创建对象有两个原因:集中数据和封装责任。这些确实是不同的东西，但在许多流行的语言中，它们都被视为“对象”。

在“clump data”的情况下，当你有一个逻辑上应该放在一起的数据集合时，你就创建了一个新对象。例如，一个 Point 是两个坐标的集合，这是一个非常好的“数据对象”。

关于“封装职责”，就是我们所说的“单一职责”原则。一个对象应该对您可以命名的一个“事物”负全部责任。例如，那个“东西”可能是“网络连接”或者可能是“绘制这个窗口”。您有一个 Connection 类和一个 Window 类等。真正的关键是命名。你知道你有一个很好的类，当它很容易命名时，它所做的一切似乎都来自你给它的名字。当难以命名时，您可能创建了错误的类。

类层次结构的关键类(class)称为替换原则(由 Barbara Liskov 正式提出)。如果您要创建一个子类，它必须能够在任何地方使用它的父类(super class)。所以 Corgi IS-A Dog，因为狗能做的一切，柯基都能做。但是，令人惊讶的是，正方形不是矩形。可以创建具有两个长度的矩形。广场不可能。 Square-Rectangle 问题可能是导致继承错误的最常见原因。一个很好的教训是，继承是解决许多问题的错误工具。您应该倾向于组合多个对象而不是继承。因此，在创建新类时，浅层次结构通常是最好的。

正如您所发现的，您所看到的许多称为“OOP”的东西只是包裹在对象中的过程编程。这对新手来说非常困惑。对于我们这些几十年来一直这样做的人来说，这非常令人困惑。你只需要看到这一点。