Java面向对象设计最佳实践 - 方法设计（二）

    这篇文章介绍方法范围设计，这种设计是API开发人员容易忽视的部分，也是相对困难和耗时的。 所谓范围，这里分为两个方面：第一，物理范围；第二，逻辑范围。

1.什么是物理范围
主要是指访问范围。Java编程语言提供了4种访问限定修饰符：public、protected、（package public）、private，这四个访问限定符的访问权限角度逐渐递减。这些修饰信息保存在类的字节码中，可以通过编译时确定和验证，这也是称为物理 范围的原因。

2.什么是逻辑范围
如果说物理范围限于访问范围的话，那么逻辑范围更加广阔，包括方法返回类型、参数类型、参数数量等。具体的介绍在下篇详细解释。

3.怎么设计范围
通过简单的解释两种范围的意义，那么下面关注怎么来设计范围。好的设计应该充分地发挥面向对象的复用特性。那么满足了复用特性的API设计就是好的设计 吗？不一定。在面向对象设计原则中，常常挂在嘴边的“高内聚、低耦合”，为了降低耦合性，应该使API之间尽可能的少了解。

例如：测量人体重的辅助类－PersonWeightCalculator，其中定义了calculate方法，传递一个Person对象作为参数，返回 double类型单位的重量值。按照业务逻辑的规定，需要了解人的性别，身高。设计中PersonWeightCalculator必须能访问 Person的gender和height的状态信息，在可能的情况中，还能访问其他无关的Person的属性信息，比如name信息。那么，这种情况就 是一种不好的“暴露”设计。留下的问题是怎么修改？
有人可能会说，既然PersonWeightCalculator耦合了Person对象，那么把Person参数替换成两个参数height和 gender。这样减少了Person类型依赖，同时，也是“API之间知道最小化”。其实，这不是一个很好的方法，尽管不少API开发人员是这么做的。 主要缺点有两个：第一，破坏了“源代码兼容性”。良好的API设计应该注意兼容性，其中有“源代码”和“二进制”兼容性。所谓的“源代码兼容性”是指，在 API的修正和增进前后，API的方法签名或者其他定义保证语法和语义的兼容。反之，则是不兼容。回到例子中，通过修改方法列表，其他调用其的地方，都需 要作出相应的修改，否则编译时错误。可以通过“开闭原则“（对增加开放，对修改关闭）来解决，添加一个新的带height和gender参数的 calculate方法，标记原来方法为Deprecated；第二，参数数量的问题，当前的算法只需要两个参数，那么怎么扩展？还是添加一个新的方法？ 当然可以这么做，不过只依赖Person对象有何不可？卖一点关子，这个内容在下篇详细介绍。

笔者的做法是，如果有必要的话，把PersonWeightCalculator类重构到Person类同包下。改变包的组织结构，对于其他调用者来说， 仅仅需要通过IDE重构功能重新导入即可，不需要改变实现代码。然后，开放height和gender属性为package public。这样做的好处是，只改变需要Person的属性的开放性，不修改业务逻辑。这样避免了修改后的风险，同时测试用例也不需要修改测试逻辑。

在JDK的API中，有不少的这样做法，比如java.lang.ThreadLocal和java.lang.Thread。

  总之，方法范围设计是很困难，不但需要很好地把握编程语言，而且全局地思考、设计和实现。这是一个过程，需要大量的时间，思考和学习，还有实践。