谨慎使用getter/setter

在工作中，已经形成了一个习惯，常常在新加一个类时，在写好一些private变量之后，会顺手自动生成相应的getter/setter方法。《Clean Code》中提到

将变量设置为private有一个理由：我们不想其他人依赖这些变量

确认，但是存在很多的规约是将public的变量使用private加getter/setter的方式来呈现，这两种方式都没关系，看个人喜好。

但我们工作中的变量真的都是public的么，很多场景并不是。

第一种是只读变量，这种情况不希望外部可以修改，只能通过配置或者其他的方式来进行初始化。

第二种是纯私有变量，这种情况完全不希望外部依赖。

只有setter的变量比较少见，控制getter/setter的方式主要是方便控制依赖，便于变量的管控。假如有一个订单模型Order，里面有一个Map结构，当bizType的key值为A的时候代表AA业务方的订单，如果把Order的Map暴露出去，就会有很多其他的业务方来根据bizType来判断AA业务订单，如果想要去使用bizType为B来表示AA的业务订单，就需要通知所有使用了Map原始值来判断的业务方来修改，因此，尽量让别人来依赖接口而非实现，而控制getter就是一种较好的途径。

除了依赖管理之外，另外一个好处就是便于阅读，如果我们都是不加思索的添加各种getter方法，就会出现类似ctx.getA().getB()这样的级联调用，除了容易出现NPE之外，还强迫阅读者去理解所有的细节，甚至去跳跃的阅读。如果谨慎的使用getter的话会去强迫自己思考有没有更加抽象的方式来提供服务，让阅读者一目了然。

为了实现策略模式的功能，可以使用多态以及单一处理器的方式来实现，单一处理器要求对象提供getter方法，然后处理器来计算所有逻辑，这种方式的好处是添加方法时在一个类修改就好了。但是我觉得这种优势并不明显，首先是所有的实现类的情况都需要考虑到，代码量并没有减少，其次如果新增了一个实现类，处理器的逻辑容易遗漏，只有在执行阶段才发现问题，而通过多态的方式在编译阶段就可以发现，因此这种情况下也推荐使用多态方式，保持变量的私有化。

多态方式实现，封装变量，隐藏实现 处理器方式实现