蒋先森のBlog

一个刚起航的后端菜鸟

0%

Effective Java 笔记一

Posted on Edited on In

最近比较空，就抽时间看了《Efffectice Java》这本书，虽然这本书的第二版和现在的Java版本有点老了，但是看了一遍后，感觉，其中的一些思想，平时写代码的时候需要注意的地方，还是讲的不错的。

用静态工厂方法代替构造器

对于Map的new，在Java的后面的版本中，已经修改了，不需要如书上说的创建一个newMap的静态工厂类，可以如下进行创建一个新的Map:

1
Map<Integer,String> map = new HashMap<>();

遇到多个构造器参数时要考虑用构建器

重叠构造器模式

这种模式就是利用重载，不断调用构造函数，生成需要的bean：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class MyClass{
    //必要的参数
    private final int one;
    private final int two;
    //可选的参数
    private final int three;
    private final int four;
    public MyClass1(int one,int two){
        this(one,two,0);
    }
    public MyClass(int one,int two,int three){
        this(one,two,three,0);
    }
    public MyClass(int one,int two,int three,int four){
        this.one=one;
        this.two=two;
        this.three=three;
        this.four=four;
    }
    @Override
    public String toString(){
        return " one="+this.one+" two="+this.two+" three="+this.three+" four="+this.four;
    }
}

从这代代码可以看出，这种写法有点复杂，个人觉得实际开发中，不会去使用

JavaB ean

使用创建对象，通过set来设置参数，这种也是在实际开发中，使用最多的。但是如果存在很多歌参数需要set，那就有点麻烦了，所以推荐builder模式。

1
user.setNation("China");

使用builder模式

在编辑器idea中，提供了丰富的插件，其中有一款Builder Generator的插件，提供了builder模式。这种生成的对象，可以选择参数。如果类的构造器或者静态工厂中具有多个参数，设计这种类时， Builder模式就是种不错的选择，特别是当大多数参数都是可选的时候。这种模式结合了重叠和JavaBeans的模式，在开发中可以使用。

使用builder模式的时候，只要如下代码使用就可以：

1
2
3
4
SimpleDTO builder = SimpleDTO.SimpleDTOBuilder.aSimpleDTO()
                .withId(1)
                .withName("金华市")
                .build();

用私有构造器或者枚举类型强化Singleton属性

Singleton在设计模式中，指的是单例模式。只需要初始化一次，之后就不需要再创建对象了。

通过私有构造器强化不可实例化的能力

避免创建不必要的对象

String

在项目中，对于String的属性，若改变量存在频繁的操作，就选择StringBuilder或者StringBuffer这两个。因为String定义的变量是不可变的，在执行+来修改变量的时候，String变量重新new一个String对象实例。详情。

使用静态工厂方法

对于同时提供了静态工厂方法(见第1条)和构造器的不可变类，通常可以使用静态工厂方法而不是构造器，以避免创建不必要的对象。例如，静态工厂方法 Boolean. valueof( String)几乎总是优先于构造器 Boolean( String)。构造器在每次被调用的时候都会创建一个新的对象，而静态工厂方法则从来不要求这样做，实际上也不会这样做。

自动装箱

要优先使用基本类型而不是装箱基本类型，要当心无意识的自动装箱。类型对象需要不断的创建。

消除过期的对象引用

避免使用终结方法

终结方法( finalizer)通常是不可预测的，也是很危险的，一般情况下是不必要的。使用终结方法会导致行为不稳定、降低性能，以及可移植性问题。当然，终结方法也有其可用之处，但是根据经验，应该避免使用终结方法。

覆盖 equals时请遵守通用约定

覆盖 equals时总要覆盖 hashCode

始终要覆盖 toString

在实体类的创建的时候，记得覆盖 toString，这样在打印日志什么的时候，就可以在日志中看到实体类中的具体数据了，而不是出现“实体类@163b91”这种日志了。

谨慎地覆盖clone

这个clone还没使用过，这几天详细的去看下。

考虑实现Comparable接口

在Java8中的Stream中，新增了一些排序的功能，详情。

客官，赏一杯coffee嘛~~~~