Lombok: Adakah alasan mengapa kami tidak dapat memiliki anotasi OptionalGetter?

Hanya untuk memberikan beberapa argumen lagi untuk menambahkan fitur ini:

• Pengambil opsional tidak bertentangan dengan desain Opsional - lihat Stuart Marks Optional talk di 55:06
• segala jenis argumen yang menentang penggunaan Opsional karena pertimbangan tinju atau kinerja tidak valid karena tujuannya adalah menjadikan Opsional sebagai jenis nilai di masa mendatang (pembicaraan yang sama pada 47:10 ) => kinerja adalah target yang bergerak tetapi solusi hari ini adalah utang teknis besok (jika Anda tidak menambahkan fitur ini).
• Guava merekomendasikan menggunakan Java.util.Optional daripada Guava yang disediakan - sumber

public class Foo {
    <strong i="5">@NonNull</strong> <strong i="6">@OptionalGetter</strong> <strong i="7">@Setter</strong>
    private String bar;
}

IMHO, @NonNull seharusnya tidak ada di sana, karena jika tidak, "Opsional" Anda akan menjadi "Wajib" (karena Anda tidak akan pernah bisa mendapatkan absent ). Saya kira, @OptionalGetter harus menyiratkan @Nullable pada bidang (dan argumen penyetel), tetapi pengambil yang dihasilkan harus dijelaskan dengan @No[tn][Nn]ull yang diinginkan pengguna (konfigurasi).

Tujuan @NonNull dalam contoh khusus ini adalah untuk lebih membatasi dalam menolak null s sebagai argumen kepada setter, yang secara efektif memungkinkan pengambil opsional hanya kosong jika belum belum. Dengan kata lain jika Foo.getBar() kosong, maka dijamin itu belum disetel. @NonNull hanya mempengaruhi konstruktor/getter yang dihasilkan, bukan?

Mungkin akan lebih jelas jika saya menulis contoh seperti ini:

public class Foo {
    <strong i="11">@NonNull</strong> <strong i="12">@OptionalGetter</strong> <strong i="13">@Setter</strong>
    private String bar = null;
}

Bagaimanapun, setelah melihat kode Lombok, saya pikir mungkin lebih mudah untuk mengimplementasikan fitur ini sebagai:

@Getter(optional=True)

Tampaknya ada banyak kode untuk mendeteksi susun anotasi Getter yang perlu diduplikasi untuk menangani OptionalGetter . Saya mungkin mencoba menerapkan dukungan sendiri di beberapa titik, tetapi secara umum, ruang lingkup proyek ini jauh di luar keahlian saya :stuck_out_tongue:

@NonNull hanya mempengaruhi konstruktor/getter yang dihasilkan, bukan?

Benar. Dan Anda benar: Tanpa membuat konstruktor, bidangnya mungkin null bahkan ketika dianotasi @NonNull . Melarang untuk menyetelnya ke null secara eksplisit mungkin masuk akal.

mungkin lebih mudah untuk mengimplementasikan fitur ini sebagai @Getter(optional=True)

Saya rasa begitu. Ini menghalangi kemungkinan untuk menghasilkan juga pengambil yang normal, tetapi memiliki dua pengambil akan menjadi sangat aneh. Saya tidak akan menyebut argumen hanya optional , melainkan useOptional atau serupa (karena pengambil tidak benar-benar opsional).

Kemungkinan yang lebih baik adalah menggunakan @UseOptionalGetters sebagai pengubah, mungkin pada tingkat kelas, atau bahkan konfigurasi, mirip seperti @Accessors bekerja.

Dalam hal pengubah di level tipe, alangkah baiknya jika anotasi validasi kacang juga didukung (@NotNull).

:+1: untuk konfigurasi getter opsional.

+1 tolong terapkan fitur ini, saya datang ke sini untuk meminta fitur ini dan melakukan pencarian dan menemukan masalah github ini. Saya dalam situasi yang sama, khususnya saya menggunakan Lombok dengan JPA, untuk menghasilkan Badan Usaha saya. Itu berfungsi dengan baik, tetapi saya ingin memiliki Pengambil Opsional, karena saya harus meninggalkan bidang itu sendiri sebagai tipe sebenarnya, karena JPA tidak tahu cara menerjemahkan Bidang Opsional.
Sesuatu seperti ini akan luar biasa:

<strong i="7">@OptionalGetter</strong> // Would create a "public Optional<VehicleType> getType()" method
@Column(nullable = true) // JPA Column Mapping
private VehicleType type;

Pembaruan 01/06/2018: Ini juga bisa menjadi sintaks yang berguna, seperti yang dirujuk sebelumnya oleh @ownaginatious

@Getter(optional=true)

Jika Anda menambahkan ini, saya akan menari di pernikahan Anda.

+1

Tidak yakin apakah kita harus membuat dua metode, pengembalian nilai "polos" dan pengembalian "wrapped-in-opsional" yang terpisah. Maksud dari Optional adalah untuk membuat kode lebih aman dan menghindari NPE. Tetapi untuk mencapai ini, konsumen tidak harus memutuskan mana dari dua pengakses yang akan digunakan. Sufiks asOptional juga terasa seperti notasi hungaria dan hanya mengulang informasi yang sudah disediakan dalam tanda tangan. (Namun, ini adalah preferensi pribadi.)

Saya lebih suka penggunaan berikut. Ini akan langsung dan menghindari ambiguitas yang muncul ketika ada dua anotasi (misalnya @OptionalGetter dan @Getter ).

@Getter(optional=true)
class MyClass {

 String foo; // -> Optional<String> getFoo()

 @Getter(optional=false) // override for individual field
 String bar; // -> String getBar()
}

(optional=false) akan menjadi default, untuk kompatibilitas mundur. Itu dapat diatur di kelas dan di tingkat bidang, di mana tingkat bidang akan diutamakan.

Saya menggunakan Lombok tetapi saat ini saya sedang menulis getter saya sendiri untuk mengembalikan Optional untuk bidang nullable dari kelas saya. Dalam kasus penggunaan ini, pengguna harus khawatir dengan boilerplate ini. Saya pikir fitur ini (seperti yang dikatakan sebelumnya @Getter(optional = true) atau yang serupa) akan menjadi fitur yang sangat diinginkan untuk Lombok, membiarkan pengguna memutuskan apakah bekerja dengan Opsional atau tidak.

Lombok sudah menyediakan mekanisme untuk menunjukkan bidang mana yang dapat dibatalkan, jadi saya melihat fitur ini sangat layak.

Mengapa tidak menjadikan bidang itu sendiri sebagai Opsional?

Pada Selasa, 22 Januari 2019 pukul 11:26 Gerard Bosch [email protected]
menulis:

Saya menggunakan Lombok tetapi saat ini saya sedang menulis getter saya sendiri untuk kembali Optional
untuk bidang yang dapat dibatalkan dari kelas saya. Dalam kasus penggunaan ini, pengguna harus khawatir
dengan boilerplate ini. Saya pikir fitur ini (seperti yang dikatakan sebelumnya @Getter(opsional
= true) atau yang serupa) akan menjadi fitur yang sangat diinginkan untuk
Lombok, membiarkan pengguna memutuskan apakah bekerja dengan Opsional atau tidak.

Lombok sudah menyediakan mekanisme untuk menunjukkan bidang mana yang dapat dibatalkan
jadi saya melihat yang satu ini fitur yang sangat layak.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rzwitserloot/lombok/issues/1214#issuecomment-456348301 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAKCRblG6QzXS4h81S12yt0-3rPwvFALks5vFudFgaJpZM4KccUJ
.

--
"Jangan hanya melatih seni Anda, tetapi paksakan jalan Anda ke dalam rahasianya, untuk itu
dan pengetahuan dapat mengangkat manusia kepada yang ilahi."
--Ludwig von Beethoven

Banyak lalu lintas ini. Maaf mengecewakan Anda semua: Kami tidak menambahkan ini. PR dengan fitur ini tidak akan diterima. Membahas kelebihan dan kekurangan dari pilihan mungkin akan memakan lebih banyak waktu dan kata-kata daripada mencari cara untuk mencapai perdamaian dunia, jadi, tolong jangan mencoba untuk memuji kebaikan opsional di sini.

@rzwitserloot Anda mungkin harus mencantumkan setidaknya beberapa alasan utama untuk tidak ingin mendukung Optional sama sekali jika Anda tidak ingin seseorang mengungkit ini lagi.

Mereka sudah membicarakannya sebelumnya
https://stackoverflow.com/questions/31670785/optional-in-lombok
https://www.voxxed.com/2015/01/embracing-void-6-refined-tricks-dealing-nulls-java/
Mereka bahkan mengutip Brian Goetz, insinyur Oracle yang memperkenalkan Opsional:

Anda hampir tidak boleh menggunakannya sebagai bidang sesuatu atau parameter metode. Saya pikir secara rutin menggunakannya sebagai nilai balik untuk getter pasti akan digunakan secara berlebihan.

Yang mengatakan, saya sangat tidak setuju dengan pendirian mereka dan saya pikir fitur ini untuk memungkinkan pengambil opsional harus diterapkan. Bahkan dalam kutipan Goetz itu, jelas bahwa _kadang-kadang_ menggunakannya sebagai nilai balik untuk pengambil masuk akal, hanya itu yang kami minta di sini.

Saya pikir argumen tentang tidak meneruskan Opsional didasarkan pada
fakta bahwa Opsional itu sendiri tidak dapat diserialkan dan itu sengaja
dirancang dengan cara ini untuk menghindari menggunakannya seperti itu jika saya tidak salah. Itu sebabnya
rekomendasi terhadap anggota kelas tipe Optional.

Tetapi sebaliknya saya dapat melihat kasus penggunaan di mana pengembalian getter can box
isian di optional, makanya saya juga mau optional Lombok
pengambil

PS vavr (lib Java hebat yang menyediakan pemrograman fungsional
konstruksi) Opsi dapat serial!

Pada Rabu, 13 Februari 2019, 16:02 Ben < [email protected] menulis:

Mereka sudah membicarakannya sebelumnya
https://stackoverflow.com/questions/31670785/optional-in-lombok

https://www.voxxed.com/2015/01/embracing-void-6-refined-tricks-dealing-nulls-java/
Mereka bahkan mengutip Brian Goetz, insinyur Oracle yang memperkenalkan Opsional:

Anda hampir tidak boleh menggunakannya sebagai bidang sesuatu atau metode
parameter. Saya pikir secara rutin menggunakannya sebagai nilai balik untuk pengambil akan
pasti akan digunakan secara berlebihan.

Yang mengatakan, saya sangat tidak setuju dengan pendirian mereka dan saya pikir fitur ini
untuk memungkinkan getter opsional harus diimplementasikan. Bahkan dalam kutipan Goetz itu
jelas bahwa terkadang menggunakannya sebagai nilai balik untuk getter membuat
akal, hanya itu yang kami minta di sini.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rzwitserloot/lombok/issues/1214#issuecomment-463231712 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AdT09IvmurwI0IHfHi-zwUq094R-AMFdks5vNCkWgaJpZM4KccUJ
.

Optional bukan pengganti null atau cara yang bagus untuk mencegah NullPointerException .

( @rspilker , https://stackoverflow.com/questions/31670785/optional-in-lombok)

Ini adalah pandangan terbatas yang tidak perlu. Antarmuka Optional mengikuti hukum monadik (sebanding dengan Maybe di Haskell dan sejenisnya) dan kalimat di atas adalah tujuan yang tepat dari struktur data tersebut ketika datang untuk mengembalikan tipe: mewakili sesuatu yang dapat hadir atau tidak ada, dan menyediakan cara standar (yaitu umum) untuk berinteraksi secara aman dengannya.

Anda hampir tidak boleh menggunakannya sebagai bidang sesuatu atau parameter metode. Saya pikir secara rutin menggunakannya sebagai nilai balik untuk getter pasti akan digunakan secara berlebihan.

(Brian Goetz, https://stackoverflow.com/questions/26327957/should-Java-8-getters-return-optional-type)

Optional tidak boleh digunakan sebagai jenis bidang, tidak ada keraguan dalam hal itu. Dan tentu saja merupakan praktik yang buruk untuk menggunakannya untuk parameter input metode juga. Namun, sangat masuk akal sebagai tipe pengembalian untuk pengakses bidang

Jadi itu salah satu dari:

// We might or might not find it:
Optional<Something> findSomethingById(<strong i="22">@NonNull</strong> String id);

// We can guarantee at compile-time that it will always be there:
<strong i="23">@NonNull</strong>
Something getSomething();

(Apakah Anda menulis anotasi atau tidak adalah cerita yang berbeda tentu saja, tetapi Anda mendapatkan idenya.)

Mungkin hanya saya tetapi di luar dunia J2EE saya benar-benar tidak melihat
titik membuat sesuatu Serializable. Selama Anda tidak menggunakan RMI di sana
adalah cara lain untuk membuat serial dan deserialise data yang tidak memerlukan itu
antarmuka. Sejauh yang saya tahu, bahkan Hibernate tidak benar-benar membutuhkannya lagi
untuk aplikasi sederhana.

Mengingat bahwa Serializable terasa seperti omong kosong lama yang sudah usang, saya tidak melihatnya
titik tidak menggunakan Opsional di mana pun Anda bisa. Tidak ada apa-apa
salah dengan bidang Opsional<> per detik. Kerangka kerja saat ini biasanya mendukung
ini baik-baik saja. Jackson melakukannya. JPA melakukannya. Hibernate agak bisa tapi tidak
(belum). Jadi apa alasannya menggunakan benda ini untuk ladang
patah semangat?

Serius: Kenapa? Orang tidak melarang penggunaan Koleksi<>, Daftar<>
atau Set<> baik, jadi mengapa Optional<> berbeda?

Pada Thu, Feb 14, 2019 at 11:35 Jan Heuermann [email protected]
menulis:

Opsional bukan pengganti nol atau cara yang bagus untuk mencegah
NullPointerException.

( @rspilker https://github.com/rspilker ,
https://stackoverflow.com/questions/31670785/optional-in-lombok)

Ini adalah pandangan terbatas yang tidak perlu. Antarmuka opsional berikut:
hukum monadik (sebanding dengan Maybe di Haskell dan sejenisnya) dan di atas
kalimat adalah tujuan yang tepat dari struktur data tersebut ketika datang ke
tipe pengembalian: mewakili sesuatu yang bisa ada atau tidak ada,
dan menyediakan cara standar (yaitu umum) untuk berinteraksi secara aman dengan
dia.

Anda hampir tidak boleh menggunakannya sebagai bidang sesuatu atau metode
parameter. Saya pikir secara rutin menggunakannya sebagai nilai balik untuk pengambil akan
pasti akan digunakan secara berlebihan.

(Brian Goetz,
https://stackoverflow.com/questions/26327957/should-Java-8-getters-return-optional-type
)

Opsional tidak boleh digunakan sebagai jenis bidang, tidak ada keraguan dalam hal itu. Dan
itu tentu praktik yang buruk untuk menggunakannya untuk parameter input metode juga.
Namun, sangat masuk akal sebagai tipe pengembalian untuk pengakses
nullable (!), karena itu pada akhirnya memungkinkan untuk yang lebih aman dan
gaya pemrograman yang lebih ketat. (“tidak rutin” != “tidak pernah”)

Jadi:

// Kami mungkin atau mungkin tidak menemukannya:
PilihanfindSomethingById( @NonNull String id);

// Kami dapat menjamin pada waktu kompilasi bahwa itu akan selalu ada:
@NonNull
Sesuatu mendapatkan Sesuatu();

(Apakah Anda menulis anotasi atau tidak adalah cerita yang berbeda dari
tentu saja, tetapi Anda mendapatkan idenya.)

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rzwitserloot/lombok/issues/1214#issuecomment-463578014 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAKCRauMa0rwQEP5-rHq-XO5T82VXRv5ks5vNTvfgaJpZM4KccUJ
.

--
"Jangan hanya melatih seni Anda, tetapi paksakan jalan Anda ke dalam rahasianya, untuk itu
dan pengetahuan dapat mengangkat manusia kepada yang ilahi."
--Ludwig von Beethoven

@randakar jika Anda Optional , maka Anda sudah dapat melakukannya hari ini dan Lombok akan menghasilkan pengambil masing-masing untuk Anda:

<strong i="8">@Getter</strong>
private Optional<Something> sth;

Inti dari utas ini adalah untuk memperkenalkan pengakses untuk bidang nullable ke Lombok yang akan membungkusnya dengan Optional "on the fly". Agar utas ini tetap fokus pada permintaan awal ini, saya sarankan untuk memindahkan diskusi umum tentang bidang opsional ke tempat yang berbeda.

Yah, saya juga tidak mendapatkan masalah dengan memperkenalkan pengambil opsional.

Mari kita perjelas: opsional adalah untuk desainer API, jadi:

1. Opsional tidak boleh digunakan sebagai argumen, sehingga mendeklarasikan bidang sebagai Opsional tidak masuk akal. Opsional BUKAN untuk mengganti null, jadi jika seseorang ingin menetapkan "tidak ada nilai" maka null harus diteruskan. Perancang API menentukan apakah nol diizinkan atau tidak, bukan Anda sebagai pengguna.

1. Mendeklarasikan bidang sebagai Opsional akan menimbulkan masalah. Coba apa pun yang memerlukan serialisasi menjadi string, seperti mengonversi ke/dari representasi JSON dan akan menjadi jelas apa rasa sakitnya. Itu karena Opsional TIDAK dirancang untuk menyimpan nilai.

2. Opsional namun WS dirancang untuk API. Itu ada untuk menunjukkan kepada pengguna bahwa nilai yang dikembalikan MUNGKIN tidak ada. Ini berarti tidak apa-apa untuk memiliki: OpsionalgetSomePossiblyOptionalProperty(). Pertimbangkan kasus kelas pengemudi yang sering diingat. API dapat menentukan bahwa beberapa properti driver OpsionalgetCache(). Begitulah cara pengguna mengetahui bahwa cache mungkin ada atau tidak dan harus menangani situasi dengan benar. Jauh lebih mudah untuk membuat kesalahan dan mengabaikan kemungkinan null jika itu hanya Cache getCache().

Meringkas saya tidak melihat kontra untuk Getter(opsional = true), hanya pro.

Tolong pertimbangkan kembali @rzwitserloot .

1. "tidak boleh digunakan" - kata siapa? Dan yang lebih penting, mengapa ? saya belum
   melihat satu alasan bagus untuk menerima nol di mana saja, sedangkan saya telah melihat banyak
   alasan untuk tidak melakukannya. Satu-satunya alasan bagus melawan Optional yang pernah saya dengar
   sejauh ini adalah antarmuka serial, yang saya anggap salah desain
   kesalahan. Dan jika Anda benar-benar membutuhkannya, masih ada alternatif Vavr
   versi ini.
2. Serialisasi menjadi string berfungsi dengan baik. Jackson melakukannya tanpa apapun
   masalah, pastikan Anda memiliki dependensi yang benar dan masukkan default
   masuk. Dan jika tidak - itu adalah bug dalam kerangka serialisasi, bukan
   penggunaan Opsional.
3. Oleh karena itu, perbedaan antara penggunaan dalam API dan penggunaan reguler adalah
   preferensi pribadi sepenuhnya buatan.

Meringkas: buat saja bidang Anda Opsional<> dan Anda benar-benar akan mendapatkan semuanya
manfaat penegakan cek nol waktu kompilasi, alih-alih meminta
solusi untuk sesuatu yang tidak masuk akal sejak awal.

Pada Kamis, 21 Februari 2019 pukul 10:47 raffig [email protected] menulis:

Yah, saya juga tidak mendapatkan masalah dengan memperkenalkan pengambil opsional.

Mari kita perjelas: opsional adalah untuk desainer API, jadi:

1.

Opsional tidak boleh digunakan sebagai argumen, sehingga menyatakan bidang sebagai
Opsional tidak masuk akal. Opsional BUKAN untuk mengganti nol, jadi jika
seseorang ingin menetapkan "tidak ada nilai" maka null harus diteruskan. desainer API
menentukan apakah nol diizinkan atau tidak, bukan Anda sebagai pengguna.
2.

Mendeklarasikan bidang sebagai Opsional akan menimbulkan masalah. Coba apa saja
yang membutuhkan serialisasi menjadi string, seperti mengonversi ke/dari JSON
representasi dan akan menjadi jelas apa rasa sakit itu. Itu karena
Opsional TIDAK dirancang untuk menyimpan nilai.
3.

Opsional namun WS dirancang untuk API. Itu ada untuk menunjukkan kepada
pengguna yang mengembalikan nilai MUNGKIN tidak ada. Ini berarti itu baik-baik saja
untuk memiliki: getSomePossiblyOptionalProperty() opsional. Pertimbangkan kasus
kelas pengemudi sering diingat. API dapat menentukan bahwa beberapa properti driver
getCache () opsional. Begitulah cara pengguna mengetahui bahwa cache mungkin atau mungkin tidak
hadir dan harus menangani situasi dengan benar. Jauh lebih mudah membuatnya
kesalahan dan abaikan kemungkinan null jika itu hanya Cache getCache().

Meringkas dan tidak melihat kontra untuk Getter (opsional = true), hanya pro.

Harap pertimbangkan kembali @rzwitserloot https://github.com/rzwitserloot .

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rzwitserloot/lombok/issues/1214#issuecomment-465932929 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAKCRVJkQZ3fpcnNwD91HJ6kl-NjTkFmks5vPmsjgaJpZM4KccUJ
.

--
"Jangan hanya melatih seni Anda, tetapi paksakan jalan Anda ke dalam rahasianya, untuk itu
dan pengetahuan dapat mengangkat manusia kepada yang ilahi."
--Ludwig von Beethoven

1. Sesuai pertanyaan mengapa itu tidak boleh digunakan sebagai argumen, jawaban singkatnya adalah: karena ada pendekatan yang lebih baik sebagai metode yang kelebihan beban. Untuk penjelasan lebih lanjut lihat artikel ini:
   http://dolszewski.com/Java/Java-8-optional-use-cases/

Anda juga dapat melihat diskusi ini: https://stackoverflow.com/questions/31922866/why-should-Java-8s-optional-not-be-used-in-arguments

1. Kadang berhasil, kadang tidak. Anggap itu sebagai bug dan tunggu selamanya untuk diperbaiki. Bahkan jika berhasil, itu adalah pemborosan sumber daya IMHO untuk mengemas/membongkar ketika tidak memiliki keunggulan praktis dibandingkan null sederhana.

2. Saya tidak mengerti maksud Anda.

Meringkas - tidak, karena dengan anotasi Setter saya mendapatkan setter (Opsional) lalu, apa desain yang buruk sesuai poin no. 1. Jadi itu bukan solusi, maaf.

Pembangun akan terlihat lebih lucu. Bayangkan: ApapunBuilder.property(Opsional).

Menjadikan bidang opsional tidak menyelesaikan apa pun dan menggunakan lebih banyak sumber daya.

1. Saya tidak melihat bagaimana metode overloading ada hubungannya dengan membuat bidang
   Opsional<>. Dan tautan yang Anda berikan menyebutkan kasus yang tepat itu sebagai yang paling banyak
   yang kontroversial, dengan " hambatan utama yang mencegah penggunaanOpsional sebagai bidang POJO adalah dukungan perpustakaan dan kerangka kerja".
   sekarang satu setengah tahun kemudian, dukungan itu telah tiba atau sedang dalam
   proses tiba, saatnya untuk mempertimbangkan kembali ini.

2. Saya menggunakannya sepanjang waktu. Berhasil. Satu atau dua tahun yang lalu itu berbeda
   cerita mungkin, tapi sekarang saya tidak pernah punya masalah dengan itu.

Adapun keuntungan praktisnya? Sehat. NullPointerException adalah yang paling
melihat bug di lingkungan produksi di seluruh dunia.
https://blog.overops.com/the-top-10-exceptions-types-in-production-Java-applications-based-on-1b-events/
Ini berarti bahwa apa pun yang dapat Anda lakukan untuk mencegah pengecualian itu terjadi
akan memiliki dampak terukur pada jumlah bug Anda. Dan Opsional<> adalah
dirancang untuk memaksa pengembang memeriksa ini, jadi ini akan membantu mencegahnya
masalah.

Adapun setter.. tidak terlalu peduli. Argumen metode kelebihan beban
argumen dari artikel itu tidak berlaku. Itu tentang memiliki metode yang
benar-benar mengambil keputusan berdasarkan apakah argumen itu opsional atau tidak. SEBUAH
setter namun hanya menempatkan objek di suatu tempat dan melupakannya. Tidak buruk
desain sama sekali, ini bahkan lebih cepat daripada membuat Opsional baru kapan pun
seseorang memanggil pengambil di bidang itu.

Pada Kamis, 21 Februari 2019 pukul 11:31 raffig [email protected] menulis:

Pembangun akan terlihat lebih lucu. Membayangkan:
ApapunBuilder.property(Opsional).

Menjadikan bidang opsional tidak menyelesaikan apa pun dan menggunakan lebih banyak sumber daya.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rzwitserloot/lombok/issues/1214#issuecomment-465947741 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAKCRVXxOeNRr3zq8ZZtkLngUjEHWtbkks5vPnWJgaJpZM4KccUJ
.

--
"Jangan hanya melatih seni Anda, tetapi paksakan jalan Anda ke dalam rahasianya, untuk itu
dan pengetahuan dapat mengangkat manusia kepada yang ilahi."
--Ludwig von Beethoven

iklan. 1. Mudah:
Bayangkan dua objek. Satu memiliki:
makeSomething(Opsional a, Opsional b, Opsional c)

Bagaimana Anda tahu kombinasi apa yang diizinkan? Semua parameter mungkin kosong? Atau mungkin a & b harus ada atau b & c? Atau mungkin setidaknya satu? Tidak ada yang tahu, kecuali Anda membaca javadoc. Jika ada :-). Bayangkan panjang javadoc itu. Bayangkan panjang kode untuk metode tersebut. Itu melanggar sebagian besar aturan desain yang baik. Buang-buang CPU, memori dan apa yang paling penting Anda sendiri, waktu yang mahal untuk membaca dua layar javadoc menjelaskan bagaimana sih metode ini harus digunakan.

Dan sekarang bayangkan objek lain dengan 3 metode:
membuat Sesuatu (a, b)
membuat Sesuatu (a, b, c)
membuatSesuatu(b)

Ah, jauh lebih jelas. Melewati hanya a dan c tidak mungkin. Aku tahu itu dalam 3 detik. Bukan javadoc? Tidak masalah! Saya masih tahu bahwa a & c tidak cukup. Setiap metode memiliki implementasi yang singkat, jelas, mudah untuk diuji dan javadoc pendek.

Mungkin Anda ingin mengatakan bahwa setA(Opsional) adalah contoh yang baik, karena mungkin nilainya bisa kosong? Nah, untuk alasan apa Anda memanggil setter itu? Untuk membersihkan setA? Hei, metode clearA() jauh lebih jelas.

Maaf, saya tidak dapat menemukan contoh bagus menggunakan opsional sebagai argumen metode. Itu hanya mendorong buruk, jauh dari desain yang jelas.

Dan ya, bantuan opsional dengan NPE. Sebagai nilai yang dikembalikan. Untuk bidang itu setidaknya bisa diperdebatkan dan untuk argumen itu hanyalah desain yang buruk.

Dan ini dia jawaban dari rekan penulis Optional Brian Goetz:
https://stackoverflow.com/questions/26327957/should-Java-8-getters-return-optional-type/26328555#26328555

Saya setuju bahwa orang dapat melakukan apa yang mereka inginkan, seseorang bahkan dapat menempelkan paku dengan obeng, namun saya tidak melihat alasan mengapa Optional Getter tidak dapat diperkenalkan ke lombok untuk orang-orang yang masih lebih suka palu.

Biarkan kami menjaga agar utas ini tetap fokus pada permintaan awal, yaitu menambahkan anotasi pengambil ke Lombok yang akan membungkus bidang nullable menjadi Optional dengan cepat. Sementara perdebatan umum tentang Optional jenis bidang atau parameter metode Optional tentu saja menarik, itu tidak membawa kita maju dalam hal itu di sini.

Saya setuju, saya baru mengerti bahwa tidak perlu atau tidak ada alasan untuk melakukan ini, tentang masalah ini ditolak dan ditutup. Inilah sebabnya saya memberikan sejumlah alasan mengapa Opsional berguna dan anotasi Pengambil Opsional akan menjadi fitur hebat.

Sulit untuk berhenti berdebat ketika seseorang salah di internet.
https://xkcd.com/386/ ;-)
Jadi jangan ragu untuk berhenti membaca.

Raffig:
Panggilan "makeSomething()" Anda tidak penting. Saya setuju Anda begitu
harus melakukan itu. Tapi itu tidak berbicara tentang membuat bidang Opsional sama sekali
jadi .. tidak relevan.

Selain itu, saya sebenarnya mencoba menghindari setter. Setter adalah untuk objek yang bisa berubah,
dan objek harus tidak berubah jika memungkinkan. Taruh @Value di
kelas dan Anda tidak akan memiliki setter.
Bahkan jika Anda harus memiliki setter, jika Anda membaca argumen melawan metode
argumen itu berbicara tentang metode yang memiliki logika kondisional berdasarkan
isi opsional. Metode yang hanya menyalin nilai ke dalam bidang
dari jenis yang sama tidak masalah. Menyebutnya dengan opsional kosong tidak apa-apa karena
baik - jika ini hanya meneruskan data yang datang dari tempat lain, itu hanya
bukan tanggung jawab bagian kode itu untuk mempedulikannya.

Terakhir, Brian Goetz - ya, itulah contoh kutipan yang terkenal. Dia
banding ke otoritas. Dia berpendapat bahwa itu tidak serial (lihat sebelumnya) dan
bahwa metode get() diberi nama yang buruk dan tidak boleh digunakan. Cukup adil.
Namun, tidak berarti Opsional tidak cocok untuk suatu bidang.

Pada Kamis, 21 Februari 2019 pukul 14:22 raffig [email protected] menulis:

Saya setuju, saya hanya mengerti bahwa tidak perlu atau tidak ada alasan untuk melakukan ini,
mengenai bahwa masalah ini ditolak dan ditutup. Inilah sebabnya saya menyediakan
sejumlah alasan mengapa Opsional berguna dan anotasi Pengambil Opsional
akan menjadi fitur yang hebat.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rzwitserloot/lombok/issues/1214#issuecomment-465997417 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAKCRY1vJQzcLjPuk5sADsQo2gNIJjR2ks5vPp2jgaJpZM4KccUJ
.

--
"Jangan hanya melatih seni Anda, tetapi paksakan jalan Anda ke dalam rahasianya, untuk itu
dan pengetahuan dapat mengangkat manusia kepada yang ilahi."
--Ludwig von Beethoven

Meringkas:

1. Ya, getter (dan metode lain yang mengembalikan nilai) harus mengembalikan Opsional jika mungkin tidak ada nilai. Jika menghitung(arg1, arg2) tidak dapat menghitung sesuatu dan tidak ada alasan pengecualian, nilai pengembalian juga harus Opsional.
2. Tidak, Opsional tidak boleh digunakan sebagai parameter - kami tidak menemukan alasan yang tepat untuk melakukan ini, setiap argumen menentang penggunaan Opsional dengan cara ini.
3. Opsional sebenarnya dapat digunakan sebagai bidang. Masalah potensial adalah serialisasi apa pun (serialisasi Java, JSON, Hibernate, dll.). Jika bukan itu masalahnya, maka sebenarnya kami tidak menemukan alasan yang baik untuk tidak menggunakan Optional as field - gunakan atau tidak, ini masalah selera.

TAPI, mengenai fitur Lombok:
Menjadikan bidang Opsional ketika pengambil DAN penyetel diperlukan tidak menyelesaikan masalah Pengambil Opsional yang hilang, karena dalam hal ini Penyetel akan menjadi buruk (lihat poin no. 2 di atas). Builder juga harus dipertimbangkan dengan bidang Opsional sehingga tidak ada metode aneh yang dibuat.

Inilah sebabnya mengapa masalah ini masih berlaku dan dibenarkan dan saya menganjurkan membuka kembali dan menerima :-)

Saya tidak berpikir masuk akal untuk berdebat di sini tentang bagaimana seseorang harus menggunakan Optional . Faktanya adalah, ada banyak pendapat yang berbeda, dengan kelompok besar di belakang masing-masing. Misalnya, bicaralah dengan siapa pun dengan latar belakang Scala yang menggunakan Java, dan mereka akan memberi tahu Anda bahwa Optional harus digunakan sebanyak mungkin sebagai pengganti null di mana pun, karena itulah cara Scala menggunakannya dengan padanannya Option . Sekarang apakah mereka benar atau salah tidak penting lagi, orang-orang dengan pendapat ini ada, dan mereka membentuk sebagian besar komunitas pengguna lombok, dan akan mendapat manfaat dari dukungan yang lebih baik untuk Optional di lombok. Sebagai contoh komunitas seperti itu, Java API for Play Framework, Lagom, dan Akka semuanya menggunakan Optional dalam bidang dan sebagai parameter metode, dan ketiga kerangka kerja tersebut merekomendasikan penggunaan lombok untuk kelas Java yang tidak dapat diubah. Ini adalah komunitas besar yang memiliki pendapat ini, itu bukan pandangan pinggiran.

Jadi pertanyaannya adalah, apakah penggunaan Optional sesuatu yang lombok sendiri harus memiliki pendapat? Saya tidak mengerti mengapa harus. Memberikan dukungan yang lebih baik untuk bidang Optional tidak akan berdampak negatif pada orang yang berpendapat bahwa Anda tidak boleh menggunakan bidang Optional , karena bidang tersebut tidak akan menggunakan Optional bidang sehingga mereka tidak akan pernah melihat dukungan itu. Tapi itu pasti akan membantu mereka yang berpendapat bahwa Anda bisa/seharusnya. Dan sepertinya itu bukan fitur yang membutuhkan biaya yang sangat tinggi untuk diimplementasikan atau memerlukan refactoring yang signifikan di lombok. Jadi mengapa bertahan pada bagian pengguna Anda ini?