[JAVA] Essayez Lombok

C'est aussi super maintenant. La lecture est "Ronboku".

Préparation

C'était plus simple de le mettre à Maven. En bref, tout va bien tant que vous passez le chemin de classe à lombok.jar.

pom.xml

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

Génération automatique de getter / setter

↓ C'est

Product.java（@Avant d'introduire les données)

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

    /*Foiré*/
    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; }
}

↓ Ce sera comme ça.

Product.java（@Après avoir introduit les données)

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

    /*Rafraîchissant!*/
}

L'appelant peut l'appeler normalement, en supposant qu'il existe un getter / setter.

python

Product product = new Product();
product.setCode("0001");
product.setName("Produit 01");
product.setPrice(BigDecimal.valueOf(10000L));

product.getCode();  // => 0001
product.getName();  // =>Produit 01
product.getPrice(); // => 10,000

J'espère que la lisibilité s'améliorera.

Génération automatique de modèle de constructeur

En ajoutant l'annotation @ Builder à Product.java mentionnée ci-dessus, l'appelant peut également effectuer les opérations suivantes.

python

Product product = Product.builder()
        .code("0001")
        .name("Produit 01")
        .price(BigDecimal.valueOf(10000L))
        .build();

En quelque sorte moderne et cool.

Au fait, est-il normal de penser que les modèles JavaBeans et Builder sont cohérents? (La spécification Java Beans a déclaré que "avoir un getter / setter" (* Je ne dis pas que je n'ai pas de méthode autre que getter / setter))

Traitez les exceptions vérifiées comme des exceptions non vérifiées

Vous n'obtiendrez pas d'erreur de compilation même si vous n'attrapez pas l'exception vérifiée chez l'appelant. Autrement dit, ↓ c'est

@Avant l'introduction de Sneaky Throws

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();
}

↓ Ce sera comme ça.

@Après avoir introduit Sneaky Throws

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

Cependant, je ne l'ai pas étudié en détail, mais je pense qu'il vaut mieux ne pas l'utiliser. Je ne comprends pas quel est le principe, mais ce n'est pas comme envelopper l'exception vérifiée dans RuntimeException, c'est juste tromper le compilateur pour empêcher l'exception vérifiée de devenir une erreur de compilation. Si vous déclenchez délibérément une NoSuchAlgorithmException dans la source ci-dessus, cela ira directement à l'appelant. Cela peut avoir des effets secondaires inattendus. Ce serait bien si nous savions qu'aucune exception ne se produirait comme la source ci-dessus (SHA-256 est toujours inclus).

Plus en détail, la couverture de Jacoco (0.8.2) n'était pas de 100% avec l'annotation SneakyThrows. Si vous dites une couverture à 100% dans votre plan de test, cela peut être un problème plus tard.

De côté

Il est normal que le getter / setter puisse être généré automatiquement, mais je suis confronté à une contradiction essentielle selon laquelle le setter JavaBeans lui-même peut être contre l'idée d'encapsulation en premier lieu. Je ne suis pas sûr de pouvoir donner une réponse satisfaisante lorsqu'on me demande: "N'est-ce pas juste une question de rendre le champ public sans le getter / setter?"