getters 与回调

《Growing Object-Oriented Software, Guided by Tests》中说，过多的 getters 意味着你暴露了过多的内部细节。这种细节包括内部的数据结构、内部的对象图。作者的团队主张“No Getters”。当然这是很极端的主张。这种主张有两个比较出名，而且充满争议的名字“Tell, Don't Ask”、“Law of Demeter”。尽量坚持 Law of Demeter 的好处是能让你提高信息隐藏的程度。我个人认为 OO 之所以受欢迎就是因为提供了一个自然地实现信息隐藏的手段。

如果你注意观察这两个链接所展示的争论你会发现极少有人否定 Law of Demeter 的意义，但是的确有很多人认为如果过分坚持这个原则会导致类臃肿。不是有这么一句名言吗，“Laws were meant to be broken”。总有时候会因为成本等原因我们会选择直接暴露内部数据结构，提供 getters。而且总有一些类的职责太简单，就是一些数据载体，比如 Point、Size 这种类。就算复杂一点，Scala 里面的 Tuple2、Tuple3，AWT 里面的 Rectangle，它们也都会不可避免地直接暴露 getters。

除去这些自身职责就是承载数据的类，其余的类我们还是可以通过方法和函数尽量去屏蔽内部数据结构和对象图。当然这样做的副作用就是你的类会变大。我们需要在类变大与内部信息隐藏之间取得一个平衡，并非完全是要么黑要么白。如果你看过比较大的系统因为信息隐藏做得糟糕而使得整个系统变成了意大利面条的话，那么你一定更倾向信息隐藏。

No Getters？面向对象的概念可不是这样子的。

No Getters 当然很极端，并不可取。但是不失为一种很好的启发式方法。如果 getters 过多，跟 setters 过多一样，都表明类有向纯数据容器的方向退化的趋势（前提是类的职责并不仅仅是容器）。这应当被看做是一种 code smell。事实上，Law of Demeter 在《Pragmatic Programmer, The From Journeyman to Master》也有提到。

退一步说，同样是简单地 return 成员变量，方法命名不一样也会带来完全不一样的抽象。减少在接口中直接暴露数据结构或暗示着这是内部数据结构的方法肯定会带来好处。