本文讨论了在面向对象软件开发中过度使用Getter可能带来的问题，提倡采用Tell Don't Ask和Law of Demeter等原则来增强信息隐藏，从而提高软件的设计质量。
《Growing Object-Oriented Software, Guided by Tests》中说，过多的 getters 意味着你暴露了过多的内部细节。这种细节包括内部的数据结构、内部的对象图。作者的团队主张“No Getters”。当然这是很极端的主张。这种主张有两个比较出名，而且充满争议的名字“[url=http://c2.com/cgi/wiki?TellDontAsk]Tell, Don't Ask[/url]”、“[url=http://c2.com/cgi/wiki?LawOfDemeter]Law of Demeter[/url]”。尽量坚持 Law of Demeter 的好处是能让你提高信息隐藏的程度。我个人认为 OO 之所以受欢迎就是因为提供了一个自然地实现信息隐藏的手段。
如果你注意观察这两个链接所展示的争论你会发现极少有人否定 Law of Demeter 的意义，但是的确有很多人认为如果过分坚持这个原则会导致类臃肿。不是有这么一句名言吗，“Laws were meant to be broken”。总有时候会因为成本等原因我们会选择直接暴露内部数据结构，提供 getters。而且总有一些类的职责太简单，就是一些数据载体，比如 Point、Size 这种类。就算复杂一点，Scala 里面的 Tuple2、Tuple3，AWT 里面的 Rectangle，它们也都会不可避免地直接暴露 getters。
除去这些自身职责就是承载数据的类，其余的类我们还是可以通过方法和函数尽量去屏蔽内部数据结构和对象图。当然这样做的副作用就是你的类会变大。我们需要在类变大与内部信息隐藏之间取得一个平衡，并非完全是要么黑要么白。如果你看过比较大的系统因为信息隐藏做得糟糕而使得整个系统变成了意大利面条的话，那么你一定更倾向信息隐藏。
如果你注意观察这两个链接所展示的争论你会发现极少有人否定 Law of Demeter 的意义，但是的确有很多人认为如果过分坚持这个原则会导致类臃肿。不是有这么一句名言吗，“Laws were meant to be broken”。总有时候会因为成本等原因我们会选择直接暴露内部数据结构，提供 getters。而且总有一些类的职责太简单，就是一些数据载体，比如 Point、Size 这种类。就算复杂一点，Scala 里面的 Tuple2、Tuple3，AWT 里面的 Rectangle，它们也都会不可避免地直接暴露 getters。
除去这些自身职责就是承载数据的类，其余的类我们还是可以通过方法和函数尽量去屏蔽内部数据结构和对象图。当然这样做的副作用就是你的类会变大。我们需要在类变大与内部信息隐藏之间取得一个平衡，并非完全是要么黑要么白。如果你看过比较大的系统因为信息隐藏做得糟糕而使得整个系统变成了意大利面条的话，那么你一定更倾向信息隐藏。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
