Mga anotasyon. Bahagi 2. Lombok

Mga anotasyon. Part 1 — medyo boring Sa bahaging ito, nagpasya akong hawakan ang Lombok library, dahil ito ay isang kilalang kinatawan ng source code annotation. Tatalakayin ko ang mga runtime annotation sa susunod na artikulo. Mga anotasyon. Bahagi 2. Lombok - 1

Noong unang panahon, may isang Java programmer. Araw-araw sumulat siya ng ordinaryong code, halimbawa, tulad nito:

package lombok;

public class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public Person() {
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        Person person = (Person) o;

        if (age != person.age) return false;
        return name != null ? name.equals(person.name) : person.name == null;
    }

    @Override
    public int hashCode() {
        int result = name != null ? name.hashCode() : 0;
        result = 31 * result + age;
        return result;
    }

    @Override
    public String toString() {
        return "Person{" +
                "name='" + name + '\'' +
                ", age=" + age +
                '}';
    }
}

Ordinaryo ang klase na ito — 2 field lang (kung minsan, may higit pa sa 10-15 field). Siyempre, ang lahat ng ito ay maaaring mabuo sa IDE. But damn it, pumapalit iyon. Kung mayroong 15-20 na mga patlang, ang bawat isa sa kanila ay nangangailangan ng mga getter, setter, constructor... Sa lahat ng ito, ang ilang iba pang mga pamamaraan, na hindi nakikita ng mata, ay madaling mawala. Paano namin matutulungan ang programmer na ito na magsulat nang mas mabilis at mas kaunti? Lombok. Sa labas ng kawali at sa apoy kasama mo. Narito ang parehong klase, ngunit ngayon ginagamit namin ang Lombok:

package lombok;

@Data
public class Person {
    private String name;
    private int age;
}

Iyon lang. Astig, ha? Ano ang ginagawa ng @Data annotation? Sa panahon ng compilation, ang anotasyong ito ay bumubuo ng mga getter/setters para sa lahat ng field, at ino-override ang toString(), equals(), at hashCode() ayon sa mga karaniwang panuntunan. Maaari mong i-install ang plugin sa IDE. Makikita nito ang anumang mga pamamaraan na hindi pa nagagawa. Mga anotasyon. Bahagi 2. Lombok - 2

Sa puntong ito, inaasahan kong ikaw, aking mambabasa, ay naging interesado, dahil ang susunod ay isang maikling pagpapakilala na may mga link sa mga detalye. Hinahayaan ka rin ng Lombok na i-customize ang pagbuo ng code, hal. lahat ng getter at setter ay hindi palaging kailangan, o maaaring kailangan mo ng ibang algorithm upang makabuo ng hash code. Upang maisakatuparan ito, may mga hiwalay na anotasyon (sa tingin ko marami sa kanila ang hindi mangangailangan ng paglalarawan): @Getter/@Setter, @ToString, @EqualsAndHashCode, @NoArgsConstructor, @RequiredArgsConstructor, at @AllArgsConstructor, @Log Ito ang pinaka karaniwan. Ang buong set ay makikita dito . Bigyang-pansin ang var at val. Nangangahulugan ito na maaari kang magsulat ng code tulad nito:

package lombok;

import lombok.experimental.var;

@Data
public class Person {
    private String name;
    private int age;

    public static void main(String[] args) {
        var person = new Person();
        person.setAge(22);
        System.out.println(person);
    }
}

Bakit kailangan ito? Halimbawa, mayroon kaming RandomAccessFileChannel na klase. Bakit gusto naming magsulat ng code na tulad nito?

RandomAccessFileChannel channel = new RandomAccessFileChannel();

Kung magagawa natin ito?

var channel2 = new RandomAccessFileChannel();

Sa aking palagay, hindi ito palaging katanggap-tanggap. Halimbawa, mayroon kaming masamang pamamaraan na nagbabalik ng masamang mapa:

public static Map<List<Set<Integer>>, Set<List<String>>> evilMap() {
    return new HashMap<>();
}

Kung tawagin mo itong ganito:

Map<List<Set<Integer>>, Set<List<String>>> listSetMap = evilMap();

Pagkatapos ito ay higit pa o hindi gaanong malinaw kung ano ang ginagawa namin. Kung ang tawag ay ganito:

var listSetMap = evilMap();

pagkatapos ay ang diyablo lamang ang nakakaalam kung ano ang babalik na evilMap() doon, at hanggang sa tingnan mo ang mismong pamamaraan, hindi mo alam. Bakit tumatakbo sa paligid ng mga source file? Sa pangkalahatan, kailangan mong mag-ingat dito. Pang-eksperimentong sangay: Dito gusto kong banggitin ang @UtilityClass annotation. Lumilikha ito ng isang pribadong tagabuo na nagtatapon ng isang pagbubukod (kaya't ang mga masasamang kamay ay hindi gumagamit ng pagmuni-muni upang makialam doon). At napakaganda nito sa simula ng isang klase — sinasabi nito sa atin na mayroong mga pamamaraan ng utility. Ipinapatupad ng @Delegate annotation ang pattern ng delegasyon. Ipagpalagay na mayroon kang isang klase na nagde-delegate ng isang bagay sa isa pang klase, at gumawa ka ng mga pagbabago sa ilan lang sa mga pamamaraan — ang anotasyong ito ay magliligtas sa iyo mula sa pagdodoble ng mga pamamaraan at susubaybayan nito ang mga ito. Kung mag-aalis o magdagdag ka ng paraan, mapapansin ang anotasyong ito. Pang-eksperimentong annotation branch GitHub Opisyal na website Upang gumana nang maayos ang IDE sa lombok at hindi i-highlight ang mga pamamaraan bilang wala, dapat mong i-install ang plugin. Ang opisyal na website ay may seksyon ng pag-setup kung saan makikita mo kung paano ikonekta ang plugin para sa bawat IDE. Gaya ng nakikita mo, sikat ang lombok: >5,000 bituin at >1,000 tinidor. Ginagamit ng tagsibol ang lombok sa mga klase nito. Kung mayroon kang Spring sa iyong proyekto, tingnan — maaaring nakuha nito ang lombok nang hindi mo nalalaman.