你编写的程序高效、优雅吗？阿里架构师教你编写高效优雅Java程序

 

面向对象

构造器参数太多怎么办？

用 builder 模式，用在

一、5 个或者 5 个以上的成员变量

二、参数很少，可是在将来，参数会增长

Builder 模式：

属于对象的建立模式，通常有

• 1. 抽象建造者：通常来讲是个接口，包含 1）建造方法，建造部件的方法（不止一

个），2）返回产品的方法

• 2. 具体建造者
• 3. 导演者，调用具体的建造者，建立产品对象
• 4. 产品，须要建造的复杂对象

对于客户端，建立导演者和具体建造者，并把具体建造者交给导演者，而后由客户端通知导演者操纵建造者进行产品的建立。

在实际的应用过程当中，有时会省略抽象建造者和导演者。

不须要实例化的类应该构造器私有

如，一些工具类提供的都是静态方法，这些类是不该该提供具体的实例的。能够参考 JDK

中的 Arrays。

不要建立没必要要的对象

1. 避免无心中建立的对象，如自动装箱

 

2. 能够在类的多个实例之间重用的成员变量，尽可能使用 static。

 

可是，要记住，是不要建立没必要要的对象，而不是不要建立对象。

对象池要谨慎使用，除非建立的对象是很是昂贵的操做，如数据库的链接，巨型对象等

等。

避免使用终结方法

finalizer 方法，jdk 不能保证什么时候执行，也不能保证必定会执行。若是有确实要释放的资源

应该用 try/finally。

使类和成员的可访问性最小化

编写程序和设计架构，最重要的目标之一就是模块之间的解耦。使类和成员的可访问性最

小化无疑是有效的途径之一。

使可变性最小化

尽可能使类不可变，不可变的类比可变的类更加易于设计、实现和使用，并且更不容易出

错，更安全。

经常使用的手段：

不提供任何能够修改对象状态的方法；

使全部的域都是 final 的。

使全部的域都是私有的。

使用写时复制机制。带来的问题：会致使系统产生大量的对象，并且性能有必定的影响，

须要在使用过程当中当心权衡。

复合优先于继承

继承容易破坏封装性，并且会使子类的实现依赖于父类。

复合则是在类中增长一个私有域，引用类的一个实例，这样的话就避免了依赖类的具体实

现。

只有在子类确实是父类的一个子类型时，才比较适合用继承。

接口优于抽象类

java 是个单继承的，可是类容许实现多个接口。

因此当发生业务变化时，新增接口，而且须要进行业务变化的类现新接口便可。可是抽象

类有可能致使不须要变化的类也不得不实现新增的业务方法。

在 JDK 里经常使用的一种设计方法是：定义一个接口，声明一个抽象的骨架类实现接口，骨架

类类实现通用的方法，而实际的业务类能够同时实现接口又继承骨架类，也能够只实现接

口。

如 HashSet 实现了 implements Set 接口 可是又 extends 类 AbstractSet，而

AbstractSet 自己也实现了 Set 接口。其余如 Map，List 都是这样的设计的。

方法

可变参数要谨慎使用

可变参数是容许传 0 个参数的

若是是参数个数在 1~多个之间的时候，要作单独的业务控制。

看代码

返回零长度的数组或集合，不要返回 null

方法的结果返回 null，会致使调用方的要单独处理为 null 的状况。返回零长度，调用方可

以统一处理，如使用 foreach 便可。

JDK 中也为咱们提供了 Collections.EMPTY_LIST 这样的零长度集合

优先使用标准的异常

要尽可能追求代码的重用，同时减小类加载的数目，提升类装载的性能。

经常使用的异常：

IlegalAraumentException -- 调用者传递的参数不合适

lllegalStateException – 接收的对象状态不对，

NullPoint

UnsupportedOperationException –不支持的操做

通用程序设计

用枚举代替 int 常量

声明的一个枚举本质就是一个类，每一个具体的枚举值就是这个枚举类的实例。

枚举更多做用，看代码。

将局部变量的做用域最小化

• 1. 在第一次使用的地方进行声明
• 2. 局部变量都是要自行初始化，初始化条件不知足，就不要声明

最小化的好处，减少局部变量表的大小，提示性能；同时避免局部变量过早声明致使不正

确的使用。

精确计算，避免使用 float 和 double

可使用 int 或者 long 以及 BigDecimal