Lombokお試し

これも超今さら。読み方は「ロンボク」。

準備

Mavenで入れるのが一番ラクでした。
要は、lombok.jarにクラスパスさえ通れば何でもいいです。

pom.xml

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.16.16</version>
    <scope>compile</scope>
</dependency>

getter/setterの自動生成

↓これが

Product.java（@Data導入前）

public class Product implements Serializable {
    private String code;
    private String name;
    private BigDecimal price;

    /* ごちゃごちゃ */
    public Product() {}
    public String getCode() { return this.code; }
    public String getName() { return this.name; }
    public BigDecimal getPrice() { return this.price; }
    public void setCode(String code) { this.code = code; }
    public void setName(String name) { this.name = name; }
    public void setPrice(BigDecimal price) { this.price = price; }
}

↓こうなる。

Product.java（@Data導入後）

@Data
public class Product implements Serializable {
    private String code;
    private String name;
    private BigDecimal price;

    /* スッキリ！ */
}

呼び出し元は、getter/setterがあるものと考えて普通に呼び出せばOK。

Product product = new Product();
product.setCode("0001");
product.setName("商品０１");
product.setPrice(BigDecimal.valueOf(10000L));

product.getCode();  // => 0001
product.getName();  // => 商品０１
product.getPrice(); // => 10,000

可読性が向上していいと思います。

Builderパターンの自動生成

前述のProduct.javaに@Builderアノテーションを付けると、呼び出し元で以下のようなこともできる。

Product product = Product.builder()
        .code("0001")
        .name("商品０１")
        .price(BigDecimal.valueOf(10000L))
        .build();

なんか今風でカッコいい。

ちなみにJavaBeansとBuilderパターンは矛盾しないと考えてＯＫ？
（JavaBeansの仕様書には「getter/setterを持つこと」（※getter/setter以外のメソッドを持つなとは言っていない）と記載してあった）

検査例外を非検査例外のように扱う

検査例外を呼び出し元でcatchしなくてもコンパイルエラーにならなくなります。
すなわち、↓これが

@SneakyThrows導入前

private String encrypt(String src) {
    MessageDigest md;
    try {
        md = MessageDigest.getInstance("SHA-256");
    } catch (NoSuchAlgorithmException e) {
        throw new RuntimeException(e);
    }

    md.update(src.getBytes());
    return md.digest();
}

↓こうなる。

@SneakyThrows導入後

@SneakyThrows
private String encrypt(String src) {
    MessageDigest md = MessageDigest.getInstance("SHA-256");
    md.update(src.getBytes());
    return md.digest();
}

ただ、詳しく調べきれていないのですがこれは使わない方がいいような気がします。どういう原理かイマイチ理解できていませんが、検査例外をRuntimeExceptionで包んでいるのではなく、検査例外がコンパイルエラーにならないようにコンパイラを騙しているだけのようなのです。前述のソースで意図的にNoSuchAlgorithmExceptionを発生させると、これが呼び出し元にそのまま飛んできます。これはこれで思わぬ副作用があるかもしれません。
前述のソースのように絶対に例外が発生しないとわかりきっている（SHA-256は必ず入っている）ならいいかもしれませんが。

あと細かい話ですが、SneakyThrowsアノテーションがついているとJacoco(0.8.2)のカバレッジが100%になりませんでした。カバレッジ100%をテスト計画でうたっていたりすると、後々面倒なことになるかもしれません。

余談

getter/setterが自動生成できるのはまあいいとして、そもそもJavaBeansのsetter自体がカプセル化の考え方に反しているのではないかという、本質的な矛盾に直面中。「getter/setter無くして、フィールドをpublicにするだけじゃダメなんですか？」と聞かれたときに満足のいく回答ができる自信がない。