《代码整洁之道》——（5）对象和数据结构

5.1、数据抽象

隐藏实现并非只是在变量之间放上一个函数层简单。隐藏实现关乎抽象！类并不简单的用取值器和赋值器将其变量推向外间，而是曝露抽象接口，以便用户无需了解数据的实现就能操作数据实体。

我们不愿曝露数据细节，更愿意以抽象形态表述数据。这并不只是用接口和/或赋值器、取值器就万事大吉。要以最好的方式呈现某个对象包含的数据，需要做严肃的思考。傻乐着乱加取值器和赋值器，是最坏

的选择。

5.2、数据、对象的反对称性

对象把数据隐藏于抽象之后，曝露操作数据的函数。数据结构曝露其数据结构，没有提供有意义的函数。

过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数，面向对象代码便于在不改动既有函数的前提下添加新类。

5.3、得墨忒耳律

著名的得墨忒耳律认为，模块不应了解它所操作对象的内部情况。得墨忒耳律认为，类C的方法f只应该调用以下对象的方法：

C
由f创建的对象
作为参数传递给f的对象
由C的实体变量持有的对象

方法不应调用由任何函数返回对象的方法。

5.3.1、火车失事

final String outputDir = ctxt.getOptions().getSractchDir().getAbsolutePath()

这类代码常被称作火车失事，因为它看起来就像是一列火车。这类连串的调用通常被认为是肮脏的风格，应该避免。最好做类似如下的切分：

Options opts = ctxt.getOptions();
File scratchDir = opts.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();

这些代码是否违反得墨忒耳律，取决于ctxt、Options和ScratchDir是对象还是数据结构。如果是对象，则它们的内部结构应当隐藏而不曝露，而有关其内部细节的知识就明显违反了得墨忒耳律。如果ctxt、Options和ScratchDir只是数据结构，没有任何行为，则它们自然会曝露其内部结构，得墨忒耳律也就不适用了。

5.3.2、混杂

这种混淆有时会不幸导致混合结构，一半是对象，一般是数据结构。这种结构拥有执行操作的函数，也有公共变量或公共访问器及改值器。无论出于怎样的初衷，公共访问器及改值器都把私有变量公开化，

诱导外部函数以过程式程序使用数据结构的方式使用这些变量。

此类混杂增加了添加新函数的难度，也增加了添加新数据结构的难度，两面不讨好。应该避免创造这种结构。它们的出现，展示了一种乱七八糟的设计，其作者不确定——或者更糟糕，完全无视——他们是否

需要函数或类型保护。

5.3.3、隐藏结构

假使ctxt、Options和ScratchDir是拥有真实行为的对象，由于对象应隐藏其内部结构，我们就不该能够看到内部结构。

5.4、数据传送对象

最为精炼的数据结构，是一个只有公共变量、没有函数的类。这种数据结构有时被称为数据传送对象，或DTO。DTO是非常有用的结构，尤其是在与数据库通信、或解析套接字传递的消息之类场景中。