第 6 章 对象和数据结构

　　将变量设置为私有（private）有一个理由：我们不想其他人依赖这些变量。

6.1 数据抽象

　　隐藏实现并非只是在变量之间放上一个函数层那么简单。隐藏实现关乎抽象！类并不简单地用取值器和赋值器将其变量推向外间，而是暴露抽象接口，以便用户无需了解数据的实现就能操作数据本体。
　　我们不愿暴露数据细节，更愿意以抽象形态表述数据，这并不只是用接口和 / 或赋值器、取值器就万事大吉。要以最好的方式呈现某个对象包含的数据，需要做严肃的思考。傻乐着乱加取值器和赋值器，是最坏的选择。

6.2 数据、对象的反对称性

　　对象把数据隐藏于抽象之后，曝露操作数据的函数。数据结构曝露其数据，没有提供有意义的函数。他们是对立的。这种差异貌似微小，但却有深远的含义。
　　过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数。面向对象代码便于在不改动既有函数的前提下添加新类。反过来讲也说得通：过程式代码难以添加新数据结构，因为必须修改所有函数。面向对象代码难以添加新函数，因为必须修改所有类。所以，对于面向对象较难的事，对于过程式代码却较容易，反之亦然。
　　在任何一个复杂系统中，都会有需要添加新数据类型而不是新函数的时候。这时，对象和面向对象就比较合适。另一方面，也会有想要添加新函数而不是数据类型的时候。在这种情况下，过程式代码和数据结构更合适。

6.3 得墨忒耳律

　　著名的得墨忒耳律（The Law of Demeter）认为，模块不应了解它所操作对象的内部情形。对象隐藏数据，曝露操作。这意味着对象不应通过存取器曝露其内部结构，因为这样更像是曝露而非隐藏其内部结构。
　　更准确地说，得墨忒耳律认为，类 C 的方法 f 只应该调用以下对象的方法：

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

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

6.3.1 火车失事

　　对象才涉及得墨忒耳律，数据结构没有任何行为，则自然会曝露其内部结构，得墨忒耳律也就不适用了。

6.3.2 混杂

　　一半是对象，一半是数据结构这种混合结构拥有执行操作的函数，也有公共变量或公共访问器及改值器。无论出于怎样的初衷，公共访问器及改值器都把私有变量公开化，诱导外部函数以过程式程序使用数据结构的方式使用这些变量。
　　此类混杂增加了新函数的难度，也增加了添加新数据结构的难度，两面不讨好。应避免创造这种结构。它们的出现，展现了一种乱七八糟的设计，其作者不确定—或者更糟糕，完全无视—它们是否需要函数或类型的保护。

6.3.3 隐藏结构

　　分析获取对象的内部结构的目的，用方法来代替获取，防止当前函数因浏览它不该知道的对象而违反德墨忒尔律。

6.4 数据传送对象

　　最为精炼的数据结构，是一个只有公共变量、没有函数的类。这种数据结构有时被称为数据传送对象，或 DTO(Data Transfer Objects)。 DTO 是非常有用的结构，尤其是在与数据库通信、或解析套接字传递的消息之类场景中。
Active Record
　　Active Record 是一种特殊的 DTO 形式。它们是拥有公共（或可豆式访问的）变量的数据结构，但通常也会拥有类似 save 和 find 这样的可浏览方法。 Active Record 一般是对数据库表或其他数据源的直接翻译。
　　经常发现开发者往这类数据结构中塞进业务规则方法，把这类数据结构当成对象来用。这是不智的行为，因为它导致了数据结构和对象的混杂体。
　　当然，解决方案就是把 Active Record 当做数据结构，并创建包含业务规则、隐藏内部数据（可能就是 Active Record 的实体）的独立对象。

6.5 小结

　　对象曝露行为，隐藏数据。便于添加新对象类型而不误修改既有行为，同时也难以在既有对象中添加新行为。数据结构曝露数据，没有明显的行为。便于向既有数据结构添加新行为，同时也难以向既有函数添加新数据结构。

6.6 文献