Project Lombok on pieni kirjasto, jota voidaan käyttää kattavasti Java-luokille kirjoitettavan Java-koodin määrän vähentämiseen. Project Lombok tekee tämän merkintöjen avulla, jotka voidaan lisätä Java-luokkaan, jolle halutaan yleisiä menetelmiä. Suurin osa merkinnöistä on nimissään itse kuvaavia: esimerkkejä ovat @Getter, @Setter, @EqualsAndHashCode, @ToString ja @NoArgsConstructor. Tässä viestissä esittelen yksinkertaisten Lombok-merkintöjen soveltamista näiden yleisesti kirjoitettujen menetelmien lisäämiseen Java-luokkaan.
Tässä on yksinkertainen luokka, jolla ei ole ennalta määritettyä ohitettua versiota toString (): sta.
ilman merkkijonoa Person.java
pakkaus pölyä.esimerkkejä; / ** * Simple Person -luokka ilman kattilaa. * * @author Dustin * / julkisen luokan henkilö {yksityinen merkkijono sukunimi; yksityinen merkkijono etunimi; } Kun yllä oleva luokka luodaan ja sen implisiittisesti peritty (Object) toString () -menetelmää kutsutaan, lähtö näyttää seuraavan kuvan mukaiselta.
Voisimme kirjoittaa nimenomaisen toString () -menetelmän tai käyttää Project Lombokia. Seuraava koodinpätkä osoittaa Project Lombok -lähestymistavan.
Person.java Lombokin @ToString-merkinnällä
pakkaus pölyä.esimerkkejä; tuoda lombok.ToString; / ** * Simple Person -luokka ilman kattilaa. * * @author Dustin * / @ToString julkisen luokan henkilö {yksityinen merkkijono sukunimi; yksityinen merkkijono etunimi; } Seuraavaksi näytetään tämän luokan sisällön tulostaminen Lombokin toimittamalla toString (): lla.
Person-objektilla on nyt parempi toString () -esitys, mutta sen kenttiä ei vieläkään alusteta, joten näemme vain nolla-arvot. Voimme käyttää Lombokia jälleen rakentajan luomiseen.
Person.java Lombokin @AllArgsConstructor -merkinnällä
pakkaus pölyä.esimerkkejä; tuoda lombok.AllArgsConstructor; tuoda lombok.ToString; / ** * Simple Person -luokka ilman kattilaa. * * @author Dustin * / @ToString @AllArgsConstructor public class Person {private String lastName; yksityinen merkkijono etunimi; } Voin nyt (itse asiassa täytyy) välittää parametrit, kun Henkilökohde havaitaan. Tulokset näkyvät seuraavassa näyttökuvassa. Tässä tapauksessa asiakaskoodissani (Main.java) näkyy kääntöaikavirhe NetBeansissa, koska NetBeans ei usko, että Henkilössä on konstruktori, joka hyväksyy kaksi merkkijonoa. Punaisista mutkikkaista merkinnöistä huolimatta koodi rakennetaan, kun pyydän NetBeansia rakentamaan sen.
Person.java-tyyppinen luokka on usein tietoluokka, jota on käytettävä vertailuissa ja mahdollisesti hashCode-pohjaisissa kokoelma-avaimissa. On tärkeää luoda yhtäläiset (Object) ja hashCode () -toteutukset oikein ja varmistaa, että ne luodaan yhdessä. Koska vanhemman Object-luokan tarjoamat oletusarvot ovat yhtäläiset ja hashCode-menetelmät, Person-instansseja käyttävä Java-koodi pystyy suorittamaan equals ja / tai hashCode, mutta ne eivät todennäköisesti ole sitä, mitä todella haluaa. Kun Suoritettava pääluokka vaihdetaan seuraavaan koodiluetteloon, näemme sen jälkeen tulosteen, joka kertoo meille, että tasa-arvon vertailu tehdään täysin identiteetin eikä sisällön perusteella.
Main.java Tämä testaa yhtä kuin () toteutus
pakkaus pölyä.esimerkkejä; tuo staattinen java.lang.System.out; / ** * Yksinkertainen pääkäyttö Project Lombok -pohjaisiin luokkiin. * * @author Dustin * / public class Main {public static void main (final String [] argumentit) {// lopullinen Person person = new Person (); lopullinen henkilöhenkilö = uusi henkilö ("Miles", "Linda"); out.println (henkilö); viimeinen merkkijono sameLastName = "Smith"; viimeinen merkkijono sameFirstName = "Sam"; lopullinen henkilö1 = uusi henkilö (samaSukunimi, sama etunimi); viimeinen henkilö henkilö2 = uusi henkilö (samaLastName, samaFirstName); if (henkilö1.yhtälö (henkilö2)) {out.println ("Sama henkilö!"); } else {out.println ("Eri ihmiset!"); }}} 
Tätä ei melkein koskaan haluta. Sen sijaan tarvitaan nimenomainen tasa-arvoinen toteutus. Pidän siitä, että Lombokin huomautus tälle, @EqualsAndHashCode, luo vain nämä molemmat yhdessä, koska ei ole järkevää nimenomaisesti ohittaa niitä erikseen. Person.java-luokan luettelo näytetään seuraavana lisäämällä @EqualsAndHashCode -merkintä.
Person.java kanssa @EqualsAndHashCode
pakkaus pölyä.esimerkkejä; tuoda lombok.AllArgsConstructor; tuo lombok.EqualsAndHashCode; tuoda lombok.ToString; / ** * Simple Person -luokka ilman kattilaa. * * @author Dustin * / @ToString @AllArgsConstructor @EqualsAndHashCode public class Person {private String lastName; yksityinen merkkijono etunimi; } Tulos on nyt parempi.
Minulla ei vieläkään ole hyvä tapa käyttää kutakin julkista kenttää tarvittaessa erikseen. Esimerkiksi, jos halusin tehdä koodissani jotain sukunimen perusteella, minulla ei ole hyvää tapaa päästä siihen tekemättä radikaaleja toimenpiteitä. Voin käyttää Lombokia täällä uudelleen.
Tässä esimerkissä oletetaan, että oletimme virheellisen oletuksen, että vain henkilön sukunimi saattaa muuttua. Tämän oletuksen vuoksi annamme vain Lombok @Setter-merkinnän sukunimelle, mutta annamme @Getter-merkinnän molemmille kentille. Muutettu Henkilökoodi näkyy seuraavaksi.
Person.java @Getterin ja @Setterin kanssa
pakkaus pölyä.esimerkkejä; tuoda lombok.AllArgsConstructor; tuo lombok.EqualsAndHashCode; tuoda lombok.Getter; tuoda lombok.Setter; tuoda lombok.ToString; / ** * Simple Person -luokka ilman kattilaa. * * @author Dustin * / @ToString @AllArgsConstructor @EqualsAndHashCode public class Person {@Getter @Setter private String lastName; @Getter private String firstName; } Tässä on päivitetty pääluokka tämän esimerkin suorittamiseksi:
Main.java, joka käyttää uutta asetinta / Getteriä
pakkaus pölyä.esimerkkejä; tuo staattinen java.lang.System.out; / ** * Yksinkertainen pääkäyttö Project Lombok -ohjattuihin luokkiin. * * @author Dustin * / public class Main {public static void main (final String [] argumentit) {// lopullinen Person person = new Person (); lopullinen henkilöhenkilö = uusi henkilö ("Miles", "Linda"); out.println (henkilö); viimeinen merkkijono sameLastName = "Smith"; viimeinen merkkijono sameFirstName = "Sam"; lopullinen henkilö1 = uusi henkilö (samaSukunimi, sama etunimi); viimeinen henkilö henkilö2 = uusi henkilö (samaLastName, samaFirstName); if (henkilö1.yhtälö (henkilö2)) {out.println ("Sama henkilö!"); } else {out.println ("Eri ihmiset!"); } lopullinen henkilö käytettävissäPerson = new Person ("Garzminski", "Gary"); out.println ("Sukunimi on" + accesPerson.getLastName ()); out.println ("Etunimi on" + accesPerson.getFirstName ()); //accessiblePerson.setFirstName("Grady "); accesPerson.setLastName ("Garfunkel"); out.println ("Uusi sukunimi on" + accesPerson.getLastName ()); }} Minun oli kommentoitava kutsu asettaa henkilön etunimi niin, että koodi rakennettaisiin. Se toimii nyt seuraavan näytön tilannekuvan mukaisesti.
On todennäköistä, että tämä Lombok-merkintöjen kokoelma olisi yleisesti toivottu, etenkin tietoihin suuntautuneille luokille. Tästä syystä Project Lombok tarjoaa yhdistetyt merkinnät, kuten @Data, jotka tarjoavat kokoelman näistä merkinnöistä. Tässä tapauksessa olisin voinut saada hyvin samanlaisen käyttäytymisen kuin useita yksittäisiä merkintöjä, jotka annoin käyttämällä @ Data. @Data-merkintä johtaa siihen, että Lombok soveltaa @Getteria kaikkiin kenttiin ja @Setter-merkintää kaikkiin ei-lopullisiin kenttiin. Toinen merkittävä ero käyttämästäni on se, että se käyttää @RequiredArgsConstructor eikä @AllArgsConstructor.
Yksi parhaista tavoista nähdä, mitä Project Lombok on tehnyt käännetylle .class-tiedostolle, on käyttää javapia. Tämä näkyy seuraavassa näytön tilannekuvassa.
Näemme tässä lähdössä, että joukko menetelmiä, joita yleisesti nähdään kattilakoodina, ovat käytettävissä käännetyssä Person.classissa. On kahden argumentin parametroitu konstruktori hashCode (), equals (Object), toString () ja odotetut get and set -menetelmät.
Lombok-projekti ei ole huolestuttava ja rajoituksetta. Monet näistä on esitetty vastauksina Hamlet D'Arcyn julkaisuun Java Without the Boilerplate - Project Lombok. Yksi rajoitus on vähentynyt tuki muissa IDE-tiedostoissa kuin Eclipse (vaikka NetBeans-tuki on kunnollista ja javacia tuetaan). Huolenaihe on se, että muilla koodia käyttävillä ja ylläpitävillä on oltava uusi riippuvuus Lombokista. Tätä huolta voidaan jonkin verran lieventää käyttämällä delombokia, jota voidaan tarvittaessa käyttää rakennusprosessissa.
Muita artikkeleita ja blogiviestejä, jotka kattavat Project Lombokin, ovat Project Lombok - Älä koskaan kirjoita Java-kattilakoodia uudelleen, Java ilman kattilalevyä - Project Lombok, Project Lombok: Bye Bye Boilerplate, Java Possen Project Lombok -haastattelu, Project Lombok: Lopeta Java-sanamuotoisuus , Project Lombok - pakollinen Java-työkalupakissa, Project Lombok: mielenkiintoiset pavun pikakuvakkeet huomautusprosessorilla, haastattelu: Reinier ja Roel Lombokissa, kattilakoodin vähentäminen Project Lombokilla, nopea kehitys Lombokilla, Lombok pienentää kattilakoodiasi ja Parempi vaihtoehto gettereille ja settereille.
Tämän tarinan, "Common Java Object Functionality with Project Lombok", julkaisi alun perin JavaWorld.
