Project Lombok ile Yağsız Java Kodu Yazın

Bu günlerde Java kodu yazdığımı hayal bile edemediğim çok sayıda araç ve kitaplık var. Geleneksel olarak, Google Guava veya Joda Time (en azından Java 8 öncesi dönem için) gibi şeyler, elimdeki belirli alandan bağımsız olarak çoğu zaman projelerime attığım bağımlılıklar arasındadır.

Lombok, tipik bir kütüphane/çerçeve yardımcı programı olmasa da, POM'larımda veya Gradle derlemelerimde yerini kesinlikle hak ediyor. Lombok bir süredir piyasada (ilk olarak 2009'da piyasaya sürüldü) ve o zamandan beri çok olgunlaştı. Bununla birlikte, her zaman daha fazla ilgiyi hak ettiğini hissettim - Java'nın doğal ayrıntısıyla başa çıkmanın harika bir yolu.

Bu yazıda, Lombok'u bu kadar kullanışlı bir araç yapan şeyin ne olduğunu keşfedeceğiz.

Java, dikkate değer bir yazılım parçası olan JVM'nin ötesinde birçok şeye sahiptir. Java olgun ve performanslıdır ve çevresindeki topluluk ve ekosistem çok büyük ve canlıdır.

Bununla birlikte, bir programlama dili olarak Java'nın kendine özgü bazı özellikleri ve onu oldukça ayrıntılı hale getirebilecek tasarım seçenekleri vardır. Java geliştiricilerinin sıklıkla kullanması gereken bazı yapılar ve sınıf kalıpları ekleyin ve sık sık, bazı kısıtlamalara veya çerçeve sözleşmelerine uymaktan başka gerçek değeri çok az olan veya hiç getirmeyen birçok kod satırıyla karşılaşırız.

İşte burada Lombok devreye giriyor. Yazmamız gereken “boilerplate” kodunun miktarını büyük ölçüde azaltmamızı sağlar. Lombok'un yaratıcıları çok zeki birkaç adam ve kesinlikle mizahtan zevk alıyorlar - geçmiş bir konferansta yaptıkları bu girişi kaçıramazsınız!

Lombok'un sihrini nasıl yaptığını ve bazı kullanım örneklerini görelim.

Lombok Nasıl Çalışır?

Lombok, derleme zamanında sınıflarınıza kod "ekleyen" bir açıklama işlemcisi görevi görür. Açıklama işleme, Java derleyicisine sürüm 5'te eklenen bir özelliktir. Buradaki fikir, kullanıcıların açıklama işlemcilerini (kendileri tarafından yazılan veya Lombok gibi üçüncü taraf bağımlılıkları aracılığıyla) derleme sınıf yoluna koyabilmeleridir. Ardından, derleme işlemi devam ederken, derleyici bir açıklama bulduğunda şöyle sorar: "Hey, sınıf yolunda bu @Annotation ile ilgilenen var mı?" Ellerini kaldıran işlemciler için, derleyici daha sonra kontrolü onlara, iyi… işlemek için derleme bağlamıyla birlikte aktarır.

Belki de açıklama işlemcileri için en yaygın durum, yeni kaynak dosyaları oluşturmak veya bir tür derleme zamanı kontrolleri yapmaktır.

Lombok gerçekten bu kategorilere girmez: Yaptığı şey, kodu temsil etmek için kullanılan derleyici veri yapılarını değiştirmek; yani, soyut sözdizimi ağacı (AST). Lombok, derleyicinin AST'sini değiştirerek, son bayt kodu oluşumunu dolaylı olarak değiştiriyor.

Bu alışılmadık ve oldukça müdahaleci yaklaşım, geleneksel olarak Lombok'un bir tür hack olarak görülmesine neden oldu. Bunu kelimenin kötü anlamında görmektense, bu tanımlamaya bir dereceye kadar katılsam da, Lombok'u "zeki, teknik olarak değerli ve orijinal bir alternatif" olarak görürdüm.

Yine de bunun bir hack olduğunu düşünen ve Lombok'u bu nedenle kullanmayan geliştiriciler var. Bu anlaşılabilir bir durum, ancak deneyimlerime göre Lombok'un üretkenlik faydaları bu endişelerin herhangi birinden daha ağır basıyor. Uzun yıllardır üretim projeleri için mutlu bir şekilde kullanıyorum.

Ayrıntılara girmeden önce, projelerimde Lombok kullanımına özellikle değer vermemin iki sebebini özetlemek istiyorum:

1. Lombok, kodumun temiz, özlü ve öz olmasına yardımcı oluyor. Lombok açıklamalı sınıflarımı çok anlamlı buluyorum ve internetteki herkes mutlaka aynı fikirde olmasa da, açıklamalı kodu genel olarak oldukça açıklayıcı buluyorum.
2. Bir projeye başladığımda ve bir etki alanı modeli düşündüğümde, devam eden bir çalışma olan ve daha fazla düşündükçe yinelemeli olarak değiştirdiğim ve onları iyileştirdiğim sınıflar yazarak başlama eğilimindeyim. Bu ilk aşamalarda Lombok, benim için oluşturduğu ortak kod kodunu hareket ettirmeye veya dönüştürmeye gerek duymadan daha hızlı hareket etmeme yardımcı oluyor.

Bean Pattern ve Ortak Nesne Yöntemleri

Kullandığımız Java araçlarının ve çerçevelerinin çoğu Bean Pattern'e dayanır. Java Beans, varsayılan sıfır bağımsız değişken yapıcısına (ve muhtemelen diğer sürümlerine) sahip olan ve durumlarını, genellikle özel alanlar tarafından desteklenen alıcılar ve ayarlayıcılar aracılığıyla ortaya koyan serileştirilebilir sınıflardır. Örneğin JPA veya JAXB veya Jackson gibi serileştirme çerçeveleri ile çalışırken bunlardan birçoğunu yazıyoruz.

Tüm nitelikler için ek bir kurucuya, anlamlı dize temsiline sahip olmak ve e-posta alanı açısından eşitlik/karma tanımlamak istediğimiz beş özniteliğe (özellik) sahip olan bu Kullanıcı çekirdeğini düşünün:

 public class User implements Serializable { private String email; private String firstName; private String lastName; private Instant registrationTs; private boolean payingCustomer; // Empty constructor implementation: ~3 lines. // Utility constructor for all attributes: ~7 lines. // Getters/setters: ~38 lines. // equals() and hashCode() as per email: ~23 lines. // toString() for all attributes: ~3 lines. // Relevant: 5 lines; Boilerplate: 74 lines => 93% meaningless code :( }

Buradaki kısalık için, tüm yöntemlerin gerçek uygulamasını dahil etmek yerine, bunun yerine yöntemleri ve gerçek uygulamaların aldığı kod satırı sayısını listeleyen yorumlar sağladım. Bu ortak kod, bu sınıf için kodun %90'ından fazlasını oluşturacaktı!

Ayrıca, daha sonra, örneğin, email emailAddress olarak değiştirmek istersem veya registrationTs Instant yerine Date olmasını istersem, o zaman almak gibi şeyleri değiştirmek için (bazı durumlarda IDE'min yardımıyla, kuşkusuz) zaman ayırmam gerekirdi. / metot adlarını ve türlerini ayarla, yardımcı program kurucumu değiştir, vb. Yine, koduma pratik bir iş değeri getirmeyen bir şey için paha biçilmez zaman.

Bakalım Lombok burada nasıl yardımcı olabilir:

 import lombok.AllArgsConstructor; import lombok.EqualsAndHashCode; import lombok.Getter; import lombok.NoArgsConstructor; import lombok.Setter; import lombok.ToString; @Getter @Setter @NoArgsConstructor @AllArgsConstructor @ToString @EqualsAndHashCode(of = {"email"}) public class User { private String email; private String firstName; private String lastName; private Instant registrationTs; private boolean payingCustomer; }

işte! Az önce bir sürü lombok.* ek açıklama ekledim ve tam da istediğimi elde ettim. Yukarıdaki liste tam olarak bunun için yazmam gereken tüm kod. Lombok, derleyici sürecime bağlanıyor ve benim için her şeyi oluşturdu (IDE'min aşağıdaki ekran görüntüsüne bakın).

Fark ettiğiniz gibi, NetBeans denetçisi (ve bu, IDE'den bağımsız olarak gerçekleşir), Lombok'un sürece getirdiği eklemeler de dahil olmak üzere derlenmiş sınıf bayt kodunu algılar. Burada yaşananlar oldukça basit:

• @Getter ve @Setter kullanarak Lombok'a tüm nitelikler için alıcılar ve ayarlayıcılar oluşturma talimatı verdim. Bunun nedeni, ek açıklamaları sınıf düzeyinde kullanmamdı. Hangi nitelikler için neyin üretileceğini seçici olarak belirtmek isteseydim, alanların kendilerine açıklama ekleyebilirdim.
• @NoArgsConstructor ve @AllArgsConstructor sayesinde, sınıfım için varsayılan bir boş kurucunun yanı sıra tüm nitelikler için ek bir kurucu elde ettim.
• @ToString ek açıklaması, varsayılan olarak adlarının önüne eklenen tüm sınıf özniteliklerini gösteren kullanışlı bir toString() yöntemini otomatik olarak oluşturur.
• Son olarak, e-posta alanı açısından tanımlanmış equals() ve hashCode() yöntemlerine sahip olmak için @EqualsAndHashCode kullandım ve ilgili alanların listesiyle (bu durumda yalnızca e-posta) parametreleştirdim.

Lombok Ek Açıklamalarını Özelleştirme

Şimdi aynı örneği izleyerek bazı Lombok özelleştirmelerini kullanalım:

• Varsayılan kurucunun görünürlüğünü azaltmak istiyorum. Yalnızca fasulye uyumluluğu nedenleriyle ihtiyacım olduğundan, sınıfın tüketicilerinin yalnızca tüm alanları alan kurucuyu aramasını bekliyorum. Bunu zorlamak için, oluşturulan AccessLevel.PACKAGE ile özelleştiriyorum.
• Alanlarıma ne yapıcı ne de ayarlayıcı yöntemlerle hiçbir zaman boş değerler atanmamasını sağlamak istiyorum. @NonNull ile sınıf niteliklerine açıklama eklemek yeterlidir; Lombok, yapıcı ve ayarlayıcı yöntemlerinde uygun olduğunda NullPointerException atan boş denetimler oluşturur.
• Bir password özniteliği ekleyeceğim, ancak güvenlik nedenleriyle toString() gösterilmesini istemiyorum. Bu, @ToString hariç tutma argümanı aracılığıyla gerçekleştirilir.
• Durumu alıcılar aracılığıyla herkese açık bir şekilde ifşa etmekteyim, ancak dış değişkenliği kısıtlamayı tercih ederim. Bu yüzden @Getter olduğu gibi bırakıyorum, ancak yine @Setter için AccessLevel.PROTECTED kullanıyorum.
• Belki email alanına bazı kısıtlamalar getirmek isterim, böylece değiştirilirse bir tür kontrol yapılır. Bunun için sadece setEmail() yöntemini kendim uyguluyorum. Lombok, zaten var olan bir yöntemin oluşturulmasını atlayacaktır.

User sınıfı şu şekilde görünecektir:

 import lombok.AccessLevel; import lombok.AllArgsConstructor; import lombok.EqualsAndHashCode; import lombok.Getter; import lombok.NoArgsConstructor; import lombok.NonNull; import lombok.Setter; import lombok.ToString; @Getter @Setter(AccessLevel.PROTECTED) @NoArgsConstructor(access = AccessLevel.PACKAGE) @AllArgsConstructor @ToString(exclude = {"password"}) @EqualsAndHashCode(of = {"email"}) public class User { private @NonNull String email; private @NonNull byte[] password; private @NonNull String firstName; private @NonNull String lastName; private @NonNull Instant registrationTs; private boolean payingCustomer; protected void setEmail(String email) { // Check for null (=> NullPointerException) // and valid email code (=> IllegalArgumentException) this.email = email; } }

Bazı ek açıklamalar için sınıf özniteliklerini düz dizeler olarak belirlediğimizi unutmayın. Sorun değil, çünkü örneğin yanlış yazarsak veya var olmayan bir alana başvurursak Lombok derleme hatası verir. Lombok ile güvendeyiz.

Ayrıca, setEmail() yönteminde olduğu gibi, Lombok da sorunsuz olacak ve programcının halihazırda uyguladığı bir yöntem için hiçbir şey üretmeyecektir. Bu, tüm yöntemler ve yapıcılar için geçerlidir.

Değişmez Veri Yapıları

Lombok'un üstün olduğu başka bir kullanım durumu, değişmez veri yapıları oluştururken olur. Bunlara genellikle “değer türleri” denir. Bazı dillerin bunlar için yerleşik desteği vardır ve bunu gelecekteki Java sürümlerine dahil etmek için bir teklif bile vardır.

Bir kullanıcı oturum açma işlemine bir yanıt modellemek istediğimizi varsayalım. Bu, yalnızca somutlaştırmak ve uygulamanın diğer katmanlarına geri dönmek istediğimiz türden bir nesnedir (örneğin, bir HTTP yanıtının gövdesi olarak JSON'un serileştirilmesi için). Böyle bir LoginResponse'un değişken olması gerekmez ve Lombok bunu kısa ve öz bir şekilde tanımlamaya yardımcı olabilir. Elbette, değişmez veri yapıları için başka birçok kullanım durumu vardır (diğer niteliklerin yanı sıra çoklu kullanım ve önbellek dostudurlar), ancak bu basit örneğe bağlı kalalım:

 import lombok.EqualsAndHashCode; import lombok.Getter; import lombok.NonNull; import lombok.RequiredArgsConstructor; import lombok.ToString; import lombok.experimental.Wither; @Getter @RequiredArgsConstructor @ToString @EqualsAndHashCode public final class LoginResponse { private final long userId; private final @NonNull String authToken; private final @NonNull Instant loginTs; @Wither private final @NonNull Instant tokenExpiryTs; }

Burada belirtmekte fayda var:

• Bir @RequiredArgsConstructor ek açıklaması tanıtıldı. Uygun bir şekilde adlandırılmış, yaptığı şey, henüz başlatılmamış tüm son alanlar için bir kurucu oluşturmaktır.
• Önceden verilmiş bir LoginResonse'ı yeniden kullanmak istediğimiz durumlarda (örneğin, bir "token yenileme" işlemi düşünün), mevcut örneğimizi kesinlikle değiştirmek istemiyoruz, bunun yerine ona dayalı yeni bir tane oluşturmak istiyoruz. . @Wither ek açıklamasının burada bize nasıl yardımcı olduğunu görün: Lombok'a, belirttiğimiz yenisi dışında tüm with'ed örnek değerlerine sahip yeni bir LoginResponse örneği oluşturan bir withTokenExpiryTs(Instant tokenExpiryTs) yöntemi oluşturmasını söyler. Bu davranışı tüm alanlar için ister misiniz? Bunun yerine sınıf bildirimine @Wither ekleyin.

@Veri ve @Değer

Şimdiye kadar tartışılan her iki kullanım durumu da o kadar yaygındır ki, Lombok onları daha da kısaltmak için birkaç ek açıklama gönderir: @Data ile bir sınıfa açıklama eklemek, Lombok'un sanki @Getter + @Setter + @ToString + ile açıklama yapılmış gibi davranmasını tetikler. @EqualsAndHashCode + @RequiredArgsConstructor . Benzer şekilde, @Value kullanmak, sınıfınızı değişmez (ve nihai) bir sınıfa dönüştürecektir, üstelik yine yukarıdaki listeye açıklama eklenmiş gibi.

Oluşturucu Modeli

Kullanıcı örneğimize geri dönersek, yeni bir örnek oluşturmak istiyorsak, altı argümana kadar bir kurucu kullanmamız gerekecek. Bu zaten oldukça büyük bir sayı, sınıfa daha fazla nitelik eklersek daha da kötüleşecek. Ayrıca, lastName ve payingCustomer alanları için bazı varsayılan değerler ayarlamak istediğimizi varsayalım.

Lombok, yeni örnekler oluşturmak için bir Oluşturucu Kalıbı kullanmamıza izin veren çok güçlü bir @Builder özelliği uygular. Bunu User sınıfımıza ekleyelim:

 import lombok.AccessLevel; import lombok.AllArgsConstructor; import lombok.Builder; import lombok.EqualsAndHashCode; import lombok.Getter; import lombok.NoArgsConstructor; import lombok.NonNull; import lombok.Setter; import lombok.ToString; @Getter @Setter(AccessLevel.PROTECTED) @NoArgsConstructor(access = AccessLevel.PACKAGE) @AllArgsConstructor @ToString(exclude = {"password"}) @EqualsAndHashCode(of = {"email"}) @Builder public class User { private @NonNull String email; private @NonNull byte[] password; private @NonNull String firstName; private @NonNull String lastName = ""; private @NonNull Instant registrationTs; private boolean payingCustomer = false; }

Artık akıcı bir şekilde şu şekilde yeni kullanıcılar oluşturabiliyoruz:

 User user = User .builder() .email("[email protected]") .password("secret".getBytes(StandardCharsets.UTF_8)) .firstName("Miguel") .registrationTs(Instant.now()) .build();

Sınıflarımız büyüdükçe bu yapının ne kadar kullanışlı hale geldiğini hayal etmek kolay.

Delegasyon/Kompozisyon

“Miras yerine kompozisyonu tercih et” gibi aklı başında kuralı takip etmek istiyorsanız, bu Java'nın gerçekten yardımcı olmadığı bir şeydir, ayrıntı açısından akıllıca. Nesneler oluşturmak istiyorsanız, genellikle her yere temsilci yöntemi çağrıları yazmanız gerekir.

Lombok bunun için @Delegate aracılığıyla bir çözüm önerir. Bir örneğe bakalım.

Yeni bir ContactInformation konseptini tanıtmak istediğimizi hayal edin. Bu, User sahip olduğu bazı bilgilerdir ve diğer sınıfların da sahip olmasını isteyebiliriz. Bunu daha sonra şunun gibi bir arayüz aracılığıyla modelleyebiliriz:

 public interface HasContactInformation { String getEmail(); String getFirstName(); String getLastName(); }

Daha sonra Lombok'u kullanarak yeni bir ContactInformation sınıfı tanıtacağız:

 import lombok.Data; @Data public class ContactInformation implements HasContactInformation { private String email; private String firstName; private String lastName; }

Ve son olarak, User ContactInformation ile oluşturacak şekilde yeniden düzenleyebilir ve arayüz sözleşmesiyle eşleşmesi için gerekli tüm yetkilendirme çağrılarını oluşturmak için Lombok'u kullanabiliriz:

 import lombok.AccessLevel; import lombok.AllArgsConstructor; import lombok.Builder; import lombok.EqualsAndHashCode; import lombok.Getter; import lombok.NoArgsConstructor; import lombok.NonNull; import lombok.Setter; import lombok.ToString; import lombok.experimental.Delegate; @Getter @Setter(AccessLevel.PROTECTED) @NoArgsConstructor(access = AccessLevel.PACKAGE) @AllArgsConstructor @ToString(exclude = {"password"}) @EqualsAndHashCode(of = {"contactInformation"}) public class User implements HasContactInformation { @Getter(AccessLevel.NONE) @Delegate(types = {HasContactInformation.class}) private final ContactInformation contactInformation = new ContactInformation(); private @NonNull byte[] password; private @NonNull Instant registrationTs; private boolean payingCustomer = false; }

HasContactInformation yöntemleri için nasıl uygulamalar yazmam gerekmediğine dikkat edin: bu Lombok'a yapmasını söylediğimiz bir şey, çağrıları ContactInformation örneğimize devrediyoruz.

Ayrıca, temsilci örneğinin dışarıdan erişilebilir olmasını istemediğim için, onu bir @Getter(AccessLevel.NONE) ile özelleştiriyorum ve bunun için alıcı oluşturmayı etkili bir şekilde önlüyorum.

Kontrol Edilen İstisnalar

Hepimizin bildiği gibi Java, işaretli ve denetlenmemiş istisnalar arasında ayrım yapar. Bu, özellikle kontrol edilen istisnaları atmak için tasarlanmış API'lerle uğraşırken ve bu nedenle biz geliştiricileri onları yakalamaya veya yöntemlerimizi bildirmeye zorlarken, istisna işleme bazen yolumuza çok fazla girdiğinden, dile yönelik tartışmalar ve eleştiriler için geleneksel bir kaynaktır. onları at.

Bu örneği düşünün:

 public class UserService { public URL buildUsersApiUrl() { try { return new URL("https://apiserver.com/users"); } catch (MalformedURLException ex) { // Malformed? Really? throw new RuntimeException(ex); } } }

Bu çok yaygın bir kalıptır: URL'mizin iyi biçimli olduğunu kesinlikle biliyoruz, ancak URL yapıcısı kontrol edilen bir istisna oluşturduğundan- ya onu yakalamaya zorlanıyoruz ya da onu atmak ve aynı durumda arayanları dışarı atmak için yöntemimizi ilan ediyoruz. Bu işaretli istisnaları bir RuntimeException içine sarmak çok kapsamlı bir uygulamadır. Kodlama yaptıkça uğraşmamız gereken kontrol edilen istisnaların sayısı artarsa ​​bu durum daha da kötüleşir.

Yani Lombok'un @SneakyThrows tam olarak bunun içindir, yöntemimizde atılacak olan tüm kontrol edilmiş istisnaları kontrolsüz bir istisna haline getirir ve bizi bu zahmetten kurtarır:

 import lombok.SneakyThrows; public class UserService { @SneakyThrows public URL buildUsersApiUrl() { return new URL("https://apiserver.com/users"); } }

Kerestecilik

Sınıflarınıza bunun gibi ne sıklıkla günlükçü örnekleri ekliyorsunuz? (SLF4J örneği)

 private static final Logger LOG = LoggerFactory.getLogger(UserService.class);

Biraz tahmin yürüteceğim. Bunu bilen Lombok'un yaratıcıları, Java platformundaki en yaygın günlükleme çerçevelerini destekleyen, özelleştirilebilir bir adla (varsayılan olarak günlüğe kaydetme seçeneği) bir günlükçü örneği oluşturan bir açıklama uyguladı. Aynen bunun gibi (yine, SLF4J tabanlı):

 import lombok.SneakyThrows; import lombok.extern.slf4j.Slf4j; @Slf4j public class UserService { @SneakyThrows public URL buildUsersApiUrl() { log.debug("Building users API URL"); return new URL("https://apiserver.com/users"); } }

Oluşturulan Kodu Açıklama

Kod oluşturmak için Lombok'u kullanırsak, aslında onları yazmadığımız için bu yöntemlere açıklama ekleme yeteneğimizi kaybedeceğiz gibi görünebilir. Ama bu gerçekten doğru değil. Bunun yerine, Lombok, gerçeği söylemek gerekirse, biraz tuhaf bir gösterim kullanarak, oluşturulan kodun nasıl açıklanmasını istediğimizi söylememize izin verir.

Bir bağımlılık enjeksiyon çerçevesinin kullanımını hedefleyen bu örneği ele alalım: Bir UserRepository ve UserApiClient referanslarını almak için yapıcı enjeksiyon kullanan bir UserService sınıfımız var.

 package com.mgl.toptal.lombok; import javax.inject.Inject; import lombok.RequiredArgsConstructor; @RequiredArgsConstructor(onConstructor = @__(@Inject)) public class UserService { private final UserRepository userRepository; private final UserApiClient userApiClient; // Instead of: // // @Inject // public UserService(UserRepository userRepository, // UserApiClient userApiClient) { // this.userRepository = userRepository; // this.userApiClient = userApiClient; // } }

Yukarıdaki örnek, oluşturulan bir kurucuya nasıl açıklama ekleneceğini gösterir. Lombok, aynı şeyi üretilen metotlar ve parametreler için de yapmamızı sağlar.

Daha Fazlasını Öğrenmek

Bu yazıda açıklanan Lombok kullanımı, kişisel olarak yıllar içinde en yararlı bulduğum özelliklere odaklanıyor. Bununla birlikte, mevcut birçok başka özellik ve özelleştirme vardır.

Lombok'un belgeleri çok bilgilendirici ve kapsamlı. Her bir özellik (açıklama) için çok ayrıntılı açıklamalar ve örneklerle ayrılmış sayfaları vardır. Bu gönderiyi ilginç bulursanız, daha fazlasını öğrenmek için sizi lombok'a ve belgelerine daha derinden dalmaya teşvik ediyorum.

Proje sitesi, Lombok'un birkaç farklı programlama ortamında nasıl kullanılacağını belgelemektedir. Kısacası, en popüler IDE'ler (Eclipse, NetBeans ve IntelliJ) desteklenir. Ben kendim düzenli olarak proje bazında birinden diğerine geçiyorum ve hepsinde Lombok'u kusursuz bir şekilde kullanıyorum.

Delombok!

Delombok, “Lombok alet zincirinin” bir parçasıdır ve çok kullanışlı olabilir. Yaptığı şey, temelde Lombok tarafından oluşturulan bayt kodunun yaptığı işlemleri gerçekleştirerek, Lombok açıklamalı kodunuz için Java kaynak kodunu oluşturmaktır.

Bu, Lombok'u benimsemeyi düşünen ancak henüz tam olarak emin olmayan kişiler için harika bir seçenektir. Kullanmaya özgürce başlayabilirsiniz ve “satıcı kilitlenmesi” olmayacaktır. Sizin veya ekibinizin daha sonra seçiminizden pişmanlık duyması durumunda, ilgili kaynak kodunu oluşturmak için her zaman delombok'u kullanabilirsiniz ve daha sonra Lombok'a herhangi bir bağımlılık bırakmadan kullanabilirsiniz.

Delombok ayrıca Lombok'un tam olarak ne yapacağını öğrenmek için harika bir araçtır. Oluşturma işleminize eklemenin çok kolay yolları var.

alternatifler

Java dünyasında, Immutables veya Google Auto Value gibi derleme zamanında kodunuzu zenginleştirmek veya değiştirmek için açıklama işlemcilerini benzer şekilde kullanan birçok araç vardır. Bunlar (ve diğerleri, kesinlikle!) Lombok'un özellikleriyle örtüşüyor. Özellikle Immutables yaklaşımını çok seviyorum ve bazı projelerde de kullandım.

Ayrıca Byte Buddy veya Javassist gibi "bayt kodu geliştirme" için benzer özellikler sağlayan başka harika araçlar olduğunu da belirtmekte fayda var. Bunlar tipik olarak çalışma zamanında çalışır ve bu yazının kapsamı dışında kendilerine ait bir dünya oluşturur.

Kısa Java

Aynı sorunlardan bazılarının ele alınmasına yardımcı olan daha deyimsel - hatta dil düzeyinde - tasarım yaklaşımları sağlayan bir dizi modern JVM hedefli dil vardır. Elbette Groovy, Scala ve Kotlin güzel örneklerdir. Ancak yalnızca Java'ya yönelik bir proje üzerinde çalışıyorsanız, Lombok programlarınızın daha özlü, anlamlı ve sürdürülebilir olmasına yardımcı olacak güzel bir araçtır.