《代码整洁之道》第六章 对象和数据结构

概述

将变量设置为私有( private)有一个理由:我们不想其他人依赖这些变量。我们还想在心血来潮时能自由修改其类型或实现。那么,为什么还是有那么多程序员给对象自动添加赋值器和取值器,将私有变量公之于众、如同它们根本就是公共变量一般呢?

1. 数据抽象

代码清单6-2的漂亮之处在于,你不知道该实现会是在矩形坐标系中还是在极坐标系中。
可能两个都不是!然而,该接口还是明白无误地呈现了一种数据结构。

不过它呈现的还不止是一个数据结构。那些方法固定了一套存取策略。你可以单独读取
某个坐标,但必须通过一次原子操作设定所有坐标。

而代码清单6-1则非常清楚地是在矩形坐标系中实现,并要求我们单个操作那些坐标。这就曝露了实现。实际上,即便变量都是私有,而且我们也通过变量取值器和赋值器使用变
量,其实现仍然曝露了。

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

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

2. 数据、对象的反对称性

对象与数据结构之间的二分原理：

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

反过来讲也说得通：
过程式代码难以添加新数据结构,因为必须修改所有函数。面向对象代码难以添加新函数,因为必须修改所有类。

所以要善用面向对象和面向过程两种编码方式，并且合理结合使用。

3. 得膜忒耳定律

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

1. C
2. 由f创建的对象;
3. 作为参数传递给f的对象
4. 由C的实体变量持有的对象。

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

如上图，这通常是个不好的写法。

4. 数据传送对象

最为精练的数据结构,是一个只有公共变量、没有函数的类。这种数据结构有时被称为数据传送对象,或DTO( Data Transfer Objects)。DTo是非常有用的结构,尤其是在与数据库通信、或解析套接字传递的消息之类场景中。在应用程序代码里一系列将原始数据转换为数据库的翻译过程中,它们往往是排头兵。

通常我们的用法是“Bean”，这么说你肯定一下就熟悉了。我们通常使用这样的“Bean”加上面向过程编码来完成日常大部分开发工作。

最后的话

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

在任何系统中,我们有时会希望能够灵活地添加新数据类型,所以更喜欢在这部分使用对象。另外一些时候,我们希望能灵活地添加新行为,这时我们更喜欢使用数据类型和过程优秀的软件开发者不带成见地了解这种情形,并依据手边工作的性质选择其中一种手段。