最近公司内部培训是关于代码重构的。代码重构的目的之一是提到代码的可读性。其实，提到代码可读性并不难，很多时候代码可读性差的原因是命名的问题，这是常被我们忽略的一个细节。接下来谈谈 Java 命名的规则和模式。（代码大全这本书里有对变量命名的详细介绍）
通用命名规则
- 名字起得在有意义的前提下尽量简短。
- 类、接口和变量的名字应当是名词。
- 方法名字应当以动词或介词开头。
- 变量、参数和方法名应当以小写字母开头
- 驼峰命名法
类和接口的命名模式
类与接口之间的命名关系
以 Spring Framework 为例，ApplicationContext 是一个接口，实现它的子类都有 ClassPathXmlApplicationContext, XmlWebApplicationContext, AnnotationConfigWebApplicationContext。从中我们看到，接口与类的命名通常可归结为，一个名词命名的接口和一些有定语修饰的名词或以这个名词为结尾的名词词组。
如果这个接口只有一个实现类（可能是因为某些技术原因必须声明一个接口），那通常类会以这个接口的名字加 Impl 来命名。
过去一段时间，接口和类通常是这样命名的 IApplicationContext 是接口名，类名是 ApplicationContext。从 OO 的角度看，这种命名方式是错误的。因为接口是对一类事物抽象的描述，它反映的是共性，而不是一种特殊的东西。而 IXxxx 的命名方式则是把接口特殊化了。
Service, Manager and Action
这三个经常被用作业务类的命名，它们有个区别呢？个人意见：
Service 通常被当做单例类的命名，而 Manager 通常是用于状态的业务类的命名。简而言之，一个是无范围（Application 范围），一个是有范围。形象的比喻是，Service 是面向大众的，而 Manager 则是有一定职权范围的。Action 的功能通常较前两者单一。
工具类的命名模式
主要有三种 XXXUtils、XXXs 和 XXXHelper。前两个是多数都是通过提供静态方法来服务的，最后一个可以提供实例方法。例子不举了，太多了。（想不出例子的同学要多努力了）
Function interface (Java 8 引入的新名字，但其实并不陌生) 命名模式
- XXXable:
Comparable,Runnable,Callable - XXXAware:
ApplicationContextAware
更多命名模式和设计模式相关
命名和重构
命名可以帮助你做代码重构。当你觉得你的名字（通常是方法名或类名）不能清晰表达你的意图时，往往意味着你应当做代码重构了。这时的原因往往是你的方法和类做了太多的事情，违反了单一职责。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
