【原】set get 是否也是接口

其实这个标题很不贴切，但回忆我当年就是通过这些关键字在互联网里寻找答案，或许只有真正意想用好接口的人才会思考setter getter方法是否也要写成接口？又或者只有面向过程思想太固化的程序员才有这个困惑。以下把我对setter getter方法的理解分享给大家。

(1)getter方法。

      首先你要清楚知道，类封装的意义，对内封装数据，对外提供服务！不会对外提供数据，既然封装了，数据必然要隐藏，而往往大部分的getter都在暴露数据的隐藏性，设计者往往有意无意地在外部类大量调用getter方法去读写数据，或许你觉得没什么问题，其问题所在是，你把数据的操作交给了外部，导致了数据外泄，从而降低了类自身的内聚性，无意中加大了类与类之间的耦合程度，之所以说耦合加大，从生活中的解释是，不是你的任务你却多做了，出问题了先找你，而最后其实要找的人不是你，应该很好理解吧。程序规模越大，getter的弊端就越明显，耦合关系就越复杂，我认为getter只会出现在工厂类等产品制造类里面，而大多数情况下，我们坚决不提供getter方法。

(2)setter方法。

      相对getter，setter显得对整个设计影响不大，它的使用分歧点在于接口，举个例子，一个接口IDisplay提供一个服务，void display();而实现它的子类有2个，而各自的依赖关系都不同，A子类依赖Game类，B子类依赖的是Keyboard类，由于注入关系，A类要持有Game类的引用，B类也有相同情况，很自然会出现setter方法，而实现层的变动，是否会影响到抽象层的变化？是否应该把setter提到抽象层去维持抽象层的稳定性呢？这些问题当时我是有想过的，或许这点小变化对修改抽象层不难，只不过是添加多一两个setter，你仔细想一下，当每个子类都依赖不同的外部类，那么子类的出现就会频繁地修改抽象层，严重违反了下层依赖上层，上层不依赖下层的原则，这会导致出现维护噩梦，所以各自的setter应该果断地写回到各自的实现类中，这是比较好的做法，但也许你会问，那么没有一个统一接口去管理子类，怎么可以统一生成依赖不同类的对象？这个问题我也有考虑过，暂时没有一个很合理的解释，不久的将来，我会把新见解写在博客。

    结语，最后我回应一下题目，setter和getter不是接口，对于抽象类，setter出现的次数也许会相对多些，而关键它们都不是接口。我再次强调大家要尽量限制自己提供getter方法，就那么多吧，希望本文对你有所帮助。