对象和数据结构

先描述一个现象：

我们将变量设置为私有（private）有一个理由，不想让外界依赖这些变量。

那么为什么还有程序员给该对象添加赋值器(setter)和取值器(getter)呢？将私有变量公之于众，如同他们是公共变量一般。

事实上，即使变量都是私有的，但我们也通过变量取值器和赋值器使用变量，其实现也被暴露了。

然后我们来看两份代码，他们实现了相同的功能，但在扩展时会有不同的问题：

过程式代码 1

对象式代码 2

 

如果给代码1的Geometry类添加一个新的函数，其形状类完全不受影响。另一方面，如果要添加一个新的形状，就得修改Geometry中所有函数来处理它。

而在代码2中，如果添加一个新的形状，则现有的函数中没有一个会受到影响，而当需要添加新函数时，所有的形状类就都需要修改了。

以上两种定义的本质是他们是截然对立的。这也是对象与数据结构之间的关系：

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

反过来说就是：

过程式代码难以添加新数据结构，因为必须修改所有函数；面向对象代码难以添加新函数，因为必须修改所有类。

回到我们开篇的讨论。隐藏实现并非只是在变量直接放上一个函数层那么简单。隐藏实现关乎着抽象。类并不简单的用取值器和赋值器将变量推向外界，而是暴露抽象接口，以便用户无需了解数据的实现就能操作数据本体。

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

要以最好的方式呈现某个对象包含的数据，需要进行严肃的思考。随意乱加取值器赋值器是最坏的选择。

关于这些内容，得墨忒耳定律解释的很清楚：

得墨忒耳定律（Law of Demeter，缩写LoD）亦被称作“最少知识原则（Principle of Least Knowledge）”，是一种软件开发的设计指导原则，特别是面向对象的程序设计。得墨忒耳定律是松耦合的一种具体案例。该原则是美国东北大学在1987年末在发明的，可以简单地以下面任一种方式总结:

1. 每个单元对于其他的单元只能拥有有限的知识：只是与当前单元紧密联系的单元；
2. 每个单元只能和它的朋友交谈：不能和陌生单元交谈；
3. 只和自己直接的朋友交谈。

这个原理的名称来源于希腊神话中的农业女神，孤独的得墨忒耳。

很多面向对象程序设计语言用"."表示对象的域的解析算符，因此得墨忒耳定律可以简单地陈述为“只使用一个.算符”。因此，a.b.Method()违反了此定律，而a.Method()不违反此定律。一个简单例子是，人可以命令一条狗行走（walk），但是不应该直接指挥狗的腿行走，应该由狗去指挥控制它的腿如何行走。

优点

得墨忒耳定律使得软件更好的可维护性与适应性。因为对象较少依赖其它对象的内部结构，可以改变对象容器（container）而不用改变它的调用者（caller）。

 

一句话总结：一个类对于其他类知道的越少越好，就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信，不和陌生人说话