- 类名首字母大写,驼峰式;方法,对象名,变量首字母小写;包名全小写
- 常数变量static final
- 对于自己创建的每一个类,都考虑置入一个main(),其中包含了用于测试那个类的代码。为使用一个项目中的类,我们没必要删除测试代码。若进行了任何形式的改动,可方便地返回测试。这些代码也可作为如何使用类的一个示例使用。
- 使类尽可能短小精悍,而且只解决一个特定的问题。
- 一个复杂的开关语句:考虑采用“多形”机制。
数量众多的方法涉及到类型差别极大的操作:考虑用几个类来分别实现。
- 许多成员变量在特征上有很大的差别:考虑使用几个类 。
- 让一切东西尽可能私有
- 任何时候只要发现类与类之间结合得非常紧密,就需要考虑是否采用内部类
尽可能细致地加上注释,并用javadoc注释文档语法生成自己的程序文档。
- 避免使用“魔术数字”,这些数字很难与代码很好地配合。如以后需要修改它,无疑会成为一场噩梦,因为根本不知道“100”到底是指“数组大小”还是“其他全然不同的东西”。所以,我们应创建一个常数,并为其使用具有说服力的描述性名称,并在整个程序中都采用常数标识符。这样可使程序更易理解以及更易维护
涉及构建器和异常的时候,通常希望重新丢弃在构建器中捕获的任何异常——如果它造成了那个对象的创建失败。这样一来,调用者就不会以为那个对象已正确地创建,从而盲目地继续。 - 尽量使用interfaces,不要使用abstract类。若已知某样东西准备成为一个基础类,那么第一个选择应是将其变成一个interface(接口)。只有在不得不使用方法定义或者成员变量的时候,才需要将其变成一个abstract(抽象)类。接口主要描述了客户希望做什么事情,而一个类则致力于(或允许)具体的实施细节
- 阅读代码的时间比写代码的时间多得多。思路清晰的设计可获得易于理解的程序,但注释、细致的解释以及一些示例往往具有不可估量的价值
警惕“过早优化”。首先让它运行起来,再考虑变得更快
- 阅读代码的时间比写代码的时间多得多。思路清晰的设计可获得易于理解的程序,但注释、细致的解释以及一些示例往往具有不可估量的价值
java基本规则
最新推荐文章于 2024-08-28 20:58:28 发布