将变量设置为private有一个理由：我们不想其他人依赖这些变量。我们还想在心血来潮的时候能自由修改其类型或实现。那为什么，还有那么多程序员要给对象自动添加赋值器和取值器，将私有变量公之于众、如同它们根本就是公共变量一般呢？
1. 数据抽象
看以下代码片段的区别。每段代码都表示笛卡尔平面上的一个点。不过，其中之一暴露了其实现，而另一个则完全隐藏了其实现。
// 片段1 具象点
public class Point {
public double x;
public double y;
}
// 片段2 抽象点
public interface Point {
double getX();
double getY();
void setCartesian(double x, double y);
double getR();
double getTheta();
void setPolar(double r, double theta);
}
片段2 漂亮之处在于，你不知道该实现会是在矩形坐标系中还是在极坐标系中。可能两个都不是！然而，该接口还是明白无误地呈现了一种数据结构。
不过它呈现的不止一种数据结构，还固定了一套存取策略。你可以单独读取某个坐标，但必须通过一次原子操作设定所有坐标。
而片段1 则非常清楚地是在矩形坐标系中实现，并要求我们单个操作哪些坐标，这就暴露了实现。实际上，即便变量都是私有，而且我们也通过变量取值器和赋值器使用变量，其实现仍然暴露了。
隐藏实现并非只是在变量之间放上一个函数层那么简单。隐藏实现关乎抽象！类并不简单地用取值器和赋值器将其变量推向外间，而是暴露抽象接口，以便用户无需了解数据结构的实现就能操作数据本体。
2. 数据、对象的反对称性
上面的例子展现了对象与数据结构之间的差异。对象把数据隐藏于抽象之后，暴露操作数据的函数。数据结构暴露其数据，没有提供有意义的函数。它们是对立的。这种差异貌似微小，但却有深远的意义。
// 过程式形状代码
public class Square {
public Point topLeft;
public double side;
}
public class Rectangle {
public Point topLeft;
public double height;
public double width;
}
public class Circle {
public Point center;
public double radius;
}
public class Geometry {
public final double PI = 3.141592653589793;
public double area(Object shape) throws NoSuchShapeException {
if (shape instanceOf Square) {
Square s = (Square) shape;
return s.side * s.side;
} else if (shape instanceOf Rectangle) {
Rectangle r = (Rectangle) shape;
return r.width * r.height;
} else if (shape instanceOf Circle) {
Circle c = (Circle) shape;
return PI * c.radius * c.radius;
}
throw new NoSuchShapeException();
}
}
上面代码展示了面向过程的代码样式。Geometry类操作三个形状类，而形状类都是简单的数据结构，没有任何行为。所有行为都在Geometry类中。
面向对象程序员可能会对此嗤之以鼻，抱怨说这是过程式代码——他们大概是对的，但是这种嘲笑并不完全正确。试想一下，如果给Geometry类添加一个primeter()函数会怎样。那么形状类根本不会因此而受影响！另一方面，如果添加一个形状类，就得修改Geometry中的所有函数来处理它。注意，这两种情形也是直接对立的。
下面来看看面向对象方案。这里area()方法是多态的，不需要Geometry类。所以，如果添加一个新的形状，现有的函数一个也不会受影响，而添加新函数时所有的形状都得修改。
public class Square implements Shape {
private Point topLeft;
private double side;
public double area() {
return side * side;
}
}
public class Rectangle implements Shape {
private Point topLeft;
private double height;
private double width;
public double area() {
return width * height;
}
}
public class Circle implements Shape {
private Point center;
private double radius;
public final double PI = 3.141592653589793;
public double area() {
return PI * radius * radius;
}
}
两种定义是截然对立的。这说明了对象与数据结构之间的二分原理：
过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数。面向对象代码便于在不改动既有函数的前提下添加新类。
反过来也说得通：
过程式代码难以添加新数据结构，因为必须修改所有函数。面向对象代码难以添加新函数，因为必须修改所有类。
所以，对于面向对象较难的事，对于过程式代码却较容易，反之亦然！
一切都是对象只是一个传说！分情况来处理采用面向对象方式还是面向过程的写法。
3. 迪米特法则(The law of Demeter)
迪米特法则又叫最少知道原则（Least Knowledge Principle，简写LKP），就是说一个对象应当对其他对象又尽可能少的了解，不和陌生人说话。
模块不应该了解它所操作的对象的内部情形。如上节所见，对象隐藏数据，暴露操作。这意味着对象不应该通过存取器暴露其内部结构，因为这样更像是暴露而非隐藏其内部结构。
更准确地说，迪米特法则认为，类C的方法f只应该调用一下对象的方法：
- C
- 由f创建的对象
- 作为参数传递给f的对象
- 由C的实体变量持有的对象
方法不应调用由任何函数返回的对象的方法。换言之，只跟朋友谈话，不和陌生人说话。
下列代码违反了迪米特法则，因为它调用了getOptions()返回值的getScratchDir()，又调用了getScratchDir()返回值的getAbsolutePath()方法。
final String outputDir = ctx.getOptions().getScratchDir().getAbsolutePath();
3.1 火车失事
这类代码常被称作火车失事。最好做如下拆分：
Options opts = ctx.getOptions();
File scratchDir = opts.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();
上述代码，如果ctx、Options、ScratchDir是对象，则它们的内部数据结构应当隐藏而不暴露，其违反了迪米特法则。如果ctx、Options、ScratchDir只是数据结构，没有任何行为，则它们自然会暴露其内部结构，迪米特法则就不适用了。
如果数据结构只是简单地拥有公共变量，没有函数，而对象则拥有私有变量和公共函数，这个问题就不那么混淆了。
3.2 混杂
混杂导致了混合结构的出现，一半是对象，一半是数据结构。无论出于怎么样的初衷，公共访问器及改值器都把私有变量公开化，诱导外部函数以过程式程序使用数据结构的方式使用这些变量。
这类混杂增加了添加新函数的难度，也增加了添加新数据结构的难度，应避免创造这种结构。
3.3 隐藏结构
假如ctx、Options、ScratchDir是拥有真实行为的对象，我们改如何改造这个呢？
两种方案来获取临时目录的绝对路径：
ctx.getAbsolutePathOfScratchDirectoryOption();
或
ctx.getScratchDirectoryOption().getAbsolutePath();
第一种方案可能导致ctx对象中方法的暴露。第二种方案是在假设ggetScratchDirectoryOption返回一个数据结构而非对象。两种方案感觉都不好。
如果ctx是一个对象，就应该要求它做点什么，而不是要求它给出内部情形。那为何我们还要得到临时目录的绝对路径呢？ 例子中源代码实际上是通过取得临时目录绝对路径来创建制定名称的临时文件。
所以，直接让ctx对象来做这件事如何？
BufferedOutputStream bos = ctx.createScrathFileStream(classFileName);
这样ctx隐藏了其内部数据结构，防止当前函数因浏览它不该知道的对象而违反了迪米特法则。
4 数据传送对象
最为精炼的数据结构，是一个只有公共变量、没有函数的类。这种数据结构有时被称为数据传送对象，或DTO（Data Transfer Objects）。
这种结构对象在用于数据库通信、或解析套接字传递的消息之类场景中，非常有用。
对这种结构经常会封装为“bean”结构，豆结构拥有赋值器和取值器操作的私有变量。这种半封装让某些OO纯化论者感觉舒服些，不过通常并没有其他好处。
5. 总结
对象暴露行为，隐藏数据。便于添加新对象类型而无需修改现有行为，同时也难以在既有对象中添加新行为。数据结构暴露数据，没有明显的行为。便于向既要数据结构添加新行为，同时也难以向既有函数添加新数据的结构。
我们应该根据手边工作的性质，灵活的选择使用对象还是数据结构。
