Membandingkan anggota Java enum: == atau equals ()?


1736

Saya tahu bahwa enum Java dikompilasi ke kelas dengan konstruktor pribadi dan sekelompok anggota statis publik. Ketika membandingkan dua anggota enum yang diberikan, saya selalu menggunakan .equals(), misalnya

public useEnums(SomeEnum a)
{
    if(a.equals(SomeEnum.SOME_ENUM_VALUE))
    {
        ...
    }
    ...
}

Namun, saya baru saja menemukan beberapa kode yang menggunakan operator sama dengan ==.equals ():

public useEnums2(SomeEnum a)
{
    if(a == SomeEnum.SOME_ENUM_VALUE)
    {
        ...
    }
    ...
}

Operator mana yang harus saya gunakan?


7
Saya baru saja menemukan pertanyaan yang sangat mirip: stackoverflow.com/questions/533922/...
Matt Ball

39
Saya terkejut bahwa dalam semua jawaban (terutama yang dari polygenelubricants yang menjelaskan secara terperinci mengapa == bekerja) bahwa manfaat besar lain dari == tidak disebutkan: bahwa ia membuat eksplisit bagaimana enum bekerja (sebagai seperangkat singleton tetap benda). Dengan equals itu membuat orang berpikir bahwa entah bagaimana bisa ada beberapa contoh dari enum 'alternatif' yang sama.
Stuart Rossiter

6
Tetap sederhana. "==" lebih mudah dibaca dan berfungsi karena enum adalah singleton secara default. Ref
lokesh

Jawaban:


1578

Keduanya secara teknis benar. Jika Anda melihat kode sumbernya .equals(), itu hanya berlaku untuk ==.

Saya menggunakan ==, bagaimanapun, karena itu akan menjadi nol aman.


64
Secara pribadi, saya tidak suka 'null safety' yang disebutkan sebagai alasan untuk menggunakan ==.
Nivas

258
@Nivas: mengapa tidak? Apakah Anda suka khawatir tentang urutan argumen Anda (yang hanya berlaku untuk membandingkan konstanta dari kiri, seperti dalam jawaban Pascal)? Apakah Anda suka selalu memeriksa bahwa suatu nilai bukan nol sebelum .equals()mengambilnya? Saya tahu saya tidak.
Matt Ball

86
Perlu diingat bahwa ketika membaca kode Anda, "==" mungkin tampak salah bagi pembaca sampai ia berbunyi dan melihat sumber untuk jenis yang terlibat, kemudian melihatnya sebagai enum. Dalam hal itu, kurang mengganggu untuk membaca ".equals ()".
Kevin Bourrillion

60
@Kevin - jika Anda tidak menggunakan IDE yang memungkinkan Anda melihat jenis secara langsung saat melihat sumbernya, Anda menipu diri sendiri - bukan masalah dengan IDE yang tepat.
MetroidFan2002

63
Terkadang kode dire-refored dan mungkin saja enum digantikan oleh kelas, di mana titik == tidak lagi dijamin benar, sedangkan yang sama terus bekerja dengan mulus. Untuk alasan ini, sederajat jelas merupakan pilihan yang lebih baik. Jika Anda menginginkan keamanan nol (karena Anda bekerja pada basis kode yang tidak ditulis untuk meminimalkan penggunaan nol), ada Apache ObjectUtils atau Objek Guava # sama dengan (atau Anda dapat memutar sendiri). Saya bahkan tidak akan menyebutkan kata "kinerja" karena takut seseorang akan menampar saya dengan buku Donald Knuth.
laszlok

1113

Apakah ==bisa digunakan enum?

Ya: enum memiliki kontrol instans ketat yang memungkinkan Anda gunakan ==untuk membandingkan instance. Inilah jaminan yang diberikan oleh spesifikasi bahasa (penekanan oleh saya):

JLS 8.9 Enum

Tipe enum tidak memiliki instance selain yang didefinisikan oleh konstanta enumnya.

Ini adalah kesalahan waktu kompilasi untuk mencoba secara eksplisit instantiate tipe enum. The final clonemetode dalam Enummemastikan bahwa enumkonstanta tidak pernah bisa dikloning, dan perlakuan khusus oleh memastikan mekanisme serialisasi yang duplikat contoh yang tidak pernah dibuat sebagai hasil dari deserialization. Instansiasi reflektif dari tipe enum dilarang. Bersama-sama, keempat hal ini memastikan bahwa tidak ada contoh enumjenis ada di luar yang ditentukan olehenum konstanta.

Karena hanya ada satu instance dari setiap enumkonstanta, diperbolehkan untuk menggunakan ==operator sebagai pengganti equalsmetode ketika membandingkan dua referensi objek jika diketahui bahwa setidaknya satu dari mereka mengacu pada enumkonstanta . ( equalsMetode dalam Enumadalah finalmetode yang hanya meminta super.equalsargumennya dan mengembalikan hasilnya, sehingga melakukan perbandingan identitas.)

Jaminan ini cukup kuat yang direkomendasikan Josh Bloch, bahwa jika Anda bersikeras menggunakan pola tunggal, cara terbaik untuk mengimplementasikannya adalah dengan menggunakan elemen tunggal enum(lihat: Java Efektif Edisi 2, Butir 3: Terapkan properti singleton dengan konstruktor pribadi atau tipe enum ; juga keamanan Thread di Singleton )


Apa perbedaan antara ==danequals ?

Sebagai pengingat, perlu dikatakan bahwa secara umum, ==BUKAN merupakan alternatif untuk equals. Ketika itu, bagaimanapun (seperti denganenum ), ada dua perbedaan penting yang perlu dipertimbangkan:

== tidak pernah melempar NullPointerException

enum Color { BLACK, WHITE };

Color nothing = null;
if (nothing == Color.BLACK);      // runs fine
if (nothing.equals(Color.BLACK)); // throws NullPointerException

== harus mengetik pemeriksaan kompatibilitas pada waktu kompilasi

enum Color { BLACK, WHITE };
enum Chiral { LEFT, RIGHT };

if (Color.BLACK.equals(Chiral.LEFT)); // compiles fine
if (Color.BLACK == Chiral.LEFT);      // DOESN'T COMPILE!!! Incompatible types!

Sebaiknya == digunakan saat berlaku?

Bloch secara khusus menyebutkan bahwa kelas yang tidak dapat diubah yang memiliki kontrol yang tepat atas instance mereka dapat menjamin klien mereka ==dapat digunakan. enumsecara khusus disebutkan untuk dicontohkan.

Butir 1: Pertimbangkan metode pabrik statis daripada konstruktor

[...] ini memungkinkan kelas yang tidak dapat diubah untuk membuat jaminan bahwa tidak ada dua instance yang sama ada: a.equals(b)jika dan hanya jika a==b. Jika suatu kelas membuat jaminan ini, maka kliennya dapat menggunakan ==operator alih-alih equals(Object)metode, yang dapat menghasilkan peningkatan kinerja. Jenis Enum memberikan jaminan ini.

Untuk meringkas, argumen untuk digunakan ==pada enumadalah:

  • Berhasil.
  • Lebih cepat.
  • Lebih aman saat dijalankan.
  • Lebih aman saat kompilasi.

27
Jawaban yang bagus tapi ... 1. Berhasil : disetujui 2. lebih cepat : buktikan untuk enum :) 3. Lebih aman saat run-time : Color nothing = null;adalah IMHO bug dan harus diperbaiki, enum Anda memiliki dua nilai, bukan tiga ( lihat komentar Tom Hawtin) 4. Lebih aman saat kompilasi : OK, tetapi equalsmasih akan kembali false. Pada akhirnya, saya tidak membelinya, saya lebih suka equals()untuk keterbacaan (lihat komentar Kevin).
Pascal Thivent

201
Ini adalah tanda hitam terhadap Jawa yang oleh sebagian orang foo.equals(bar)dianggap lebih mudah dibaca daripadafoo == bar
Bennett McElwee

19
Ini berfungsi: Sampai Anda perlu mengganti enum dengan kelas sebagai bagian dari refactoring. Selamat mencoba menemukan semua kode menggunakan == yang rusak. Lebih cepat: Sekalipun benar (dipertanyakan), ada kutipan Knuth tentang pengoptimalan prematur. Lebih aman saat berjalan: "Aman" bukan kata pertama yang muncul jika penggunaan == adalah satu-satunya hal yang memisahkan Anda dari NullPointerException. Lebih aman saat kompilasi: Tidak juga. Ini dapat melindungi Anda dari kesalahan yang agak mendasar yaitu membandingkan tipe yang salah, tetapi sekali lagi, jika begitulah programmer Anda, "aman" adalah satu-satunya hal yang tidak Anda lakukan.
laszlok

35
"Jika begitu bodohnya programmer Anda," aman "adalah satu-satunya hal yang tidak Anda lakukan." - Saya tidak setuju dengan kutipan ini. Inilah yang dimaksud dengan jenis pemeriksaan: mencegah kesalahan "bodoh" pada waktu kompilasi, bahkan sebelum kode dijalankan. Bahkan orang pintar melakukan kesalahan bodoh, lebih baik beberapa jaminan daripada janji.
ymajoros

7
@laszlok: tentu, tetapi jika semuanya bisa gagal, mereka hanya akan melakukannya. Memiliki pagar untuk beberapa kesalahan bodoh selalu merupakan hal yang baik. Ada banyak ruang untuk berkreasi agar bug tidak terlalu sepele, biarkan kompiler menangani yang ini sebelum Anda mencoba menjalankan kode Anda.
ymajoros

88

Menggunakan == untuk membandingkan dua nilai enum bekerja, karena hanya ada satu objek untuk setiap konstanta enum.

Di samping catatan, sebenarnya tidak perlu menggunakan ==untuk menulis kode null-safe, jika Anda menulis equals()seperti ini:

public useEnums(final SomeEnum a) {
    if (SomeEnum.SOME_ENUM_VALUE.equals(a)) {
        
    }
    
}

Ini adalah praktik terbaik yang dikenal sebagai Bandingkan Konstanta Dari Kiri yang harus Anda ikuti.


9
Saya melakukan ini ketika .equals()nilai-nilai string, tetapi saya masih berpikir bahwa itu adalah cara jelek untuk menulis kode null-safe. Saya lebih suka memiliki operator (atau metode, tetapi saya tahu bahwa [objek nol]. Setara tidak akan pernah menjadi null-safe di Jawa karena cara kerja operator titik) yang selalu null-safe, terlepas dari memesannya digunakan. Semantik, operator "sama" harus selalu bolak-balik.
Matt Ball

2
Yah, karena Java tidak memiliki operator Navigasi Aman Groovy ( ?.), saya akan terus menggunakan praktik ini ketika membandingkan dengan konstanta dan, TBH, saya tidak merasa jelek, mungkin hanya kurang "alami".
Pascal Thivent

32
Sebuah nullenum biasanya kesalahan. Anda mendapatkan enumerasi untuk semua nilai yang mungkin, dan ini yang lain!
Tom Hawtin - tackline

8
Kecuali untuk nilai-nilai yang secara eksplisit dianotasi sebagai @Nullable, saya menganggap Bandingkan Konstanta Dari Kiri sebagai antipattern karena menyebarkan ambiguitas tentang nilai mana yang bisa atau tidak bisa nol. Jenis Enum seharusnya hampir tidak pernah @Nullable, jadi nilai nol akan menjadi kesalahan pemrograman; dalam kasus seperti itu, semakin cepat Anda melempar NPE, semakin besar kemungkinan Anda akan menemukan kesalahan pemrograman di mana Anda membiarkannya nol. Jadi "praktik terbaik ... yang harus Anda ikuti" jelas salah dalam hal tipe enum.
Tobias

24
Bandingkan Constants From The Left praktik terbaik seperti gaya bahasa Inggris terbaik Yoda.
maaartinus

58

Seperti yang orang lain katakan, keduanya ==dan.equals() bekerja dalam kebanyakan kasus. Kepastian waktu kompilasi bahwa Anda tidak membandingkan jenis Objek yang sama sekali berbeda yang orang lain tunjukkan adalah valid dan bermanfaat, namun jenis bug tertentu membandingkan objek dari dua jenis waktu kompilasi yang berbeda juga akan ditemukan oleh FindBugs (dan mungkin oleh Eclipse / IntelliJ mengkompilasi waktu inspeksi), sehingga Java compiler menemukannya tidak menambah banyak keamanan ekstra.

Namun:

  1. Fakta bahwa ==tidak pernah melempar NPE dalam pikiran saya adalah kelemahan dari ==. Seharusnya hampir tidak pernah ada kebutuhan untuk enumjenis null, karena setiap keadaan tambahan yang Anda mungkin ingin ungkapkan via nullhanya dapat ditambahkan enumsebagai contoh tambahan. Jika tidak terduga null, saya lebih suka memiliki NPE daripada ==diam - diam mengevaluasi ke false. Oleh karena itu saya tidak setuju dengan itu lebih aman di opini run-time ; lebih baik untuk membiasakan diri untuk tidak membiarkan enumnilai-nilai itu terjadi @Nullable.
  2. Argumen bahwa ==adalah lebih cepat juga palsu. Dalam kebanyakan kasus, Anda akan menelepon .equals()pada variabel yang tipe waktu kompilasi adalah kelas enum, dan dalam kasus-kasus compiler dapat tahu bahwa ini adalah sama dengan ==(karena seorang enum's equals()metode tidak bisa ditimpa) dan dapat mengoptimalkan fungsi panggilan jauh. Saya tidak yakin apakah kompiler saat ini melakukan ini, tetapi jika tidak, dan ternyata menjadi masalah kinerja di Jawa secara keseluruhan, maka saya lebih suka memperbaiki kompiler daripada memiliki 100.000 programmer Java mengubah gaya pemrograman mereka sesuai karakteristik kinerja versi kompiler tertentu.
  3. enumsadalah Objects. Untuk semua jenis Objek lainnya, perbandingan standarnya adalah .equals(), bukan ==. Saya pikir itu berbahaya untuk membuat pengecualian enumskarena Anda mungkin akhirnya secara tidak sengaja membandingkan Objek dengan, ==bukan equals(), terutama jika Anda mereformasi suatu enumke dalam kelas non-enum. Dalam hal refactoring seperti itu, titik kerjanya dari atas salah. Untuk meyakinkan diri sendiri bahwa penggunaan kata ==benar, Anda perlu memeriksa apakah nilai yang dipermasalahkan adalah enumprimitif; jika itu bukan enumkelas, itu akan salah tetapi mudah dilewatkan karena kode masih akan dikompilasi. Satu-satunya kasus ketika penggunaan.equals()yang salah adalah jika nilai-nilai tersebut primitif; dalam hal ini, kode tidak akan dikompilasi sehingga lebih sulit untuk dilewatkan. Oleh karena itu, .equals()lebih mudah untuk mengidentifikasi sebagai yang benar, dan lebih aman terhadap refactoring di masa depan.

Saya benar-benar berpikir bahwa bahasa Jawa seharusnya telah mendefinisikan == pada Objek untuk memanggil .equals () pada nilai sebelah kiri, dan memperkenalkan operator terpisah untuk identitas objek, tetapi bukan itu yang didefinisikan Java.

Singkatnya, saya masih berpikir argumennya mendukung penggunaan .equals()untuk enumtipe.


4
Nah, tentang poin 3, saya bisa menggunakan enumsebagai switchtarget sehingga mereka agak istimewa. Strings juga agak istimewa.
CurtainDog

Sintaks untuk pernyataan switch tidak mengandung == atau .equals () jadi saya tidak mengerti maksud Anda. Poin saya 3.) adalah tentang betapa mudahnya kode memverifikasi untuk pembaca. Semantik kesetaraan pernyataan pernyataan benar selama pernyataan beralih mengkompilasi.
Tobias

17

Saya lebih suka menggunakan ==daripada equals:

Alasan lain, selain yang sudah dibahas di sini, adalah Anda bisa memperkenalkan bug tanpa menyadarinya. Misalkan Anda memiliki enum ini yang persis sama tetapi dalam pacakges terpisah (itu tidak umum, tetapi itu bisa terjadi):

Enum pertama :

package first.pckg

public enum Category {
    JAZZ,
    ROCK,
    POP,
    POP_ROCK
}

Enum kedua:

package second.pckg

public enum Category {
    JAZZ,
    ROCK,
    POP,
    POP_ROCK
}

Kemudian misalkan Anda menggunakan equals seperti berikutnya dalam item.categoryyang first.pckg.Categorytetapi Anda mengimpor enum kedua ( second.pckg.Category) bukan yang pertama tanpa menyadarinya:

import second.pckg.Category;
...

Category.JAZZ.equals(item.getCategory())

Jadi Anda akan mendapatkan allways falsekarena merupakan enum berbeda walaupun Anda harapkan karena benar item.getCategory()adalah JAZZ. Dan itu bisa agak sulit dilihat.

Jadi, jika Anda menggunakan operator, ==Anda akan memiliki kesalahan kompilasi:

operator == tidak dapat diterapkan ke "second.pckg.Category", "first.pckg.Category"

import second.pckg.Category; 
...

Category.JAZZ == item.getCategory() 

Poin yang sangat bagus yang Anda sebutkan. Jadi apa yang akan saya lakukan adalah applay myenum.value () dan kemudian melakukan perbandingan == untuk keamanan NPE.
Java Main

14

Berikut ini adalah tes waktu kasar untuk membandingkan keduanya:

import java.util.Date;

public class EnumCompareSpeedTest {

    static enum TestEnum {ONE, TWO, THREE }

    public static void main(String [] args) {

        Date before = new Date();
        int c = 0;

        for(int y=0;y<5;++y) {
            for(int x=0;x<Integer.MAX_VALUE;++x) {
                if(TestEnum.ONE.equals(TestEnum.TWO)) {++c;}
                if(TestEnum.ONE == TestEnum.TWO){++c;}              
            }
        }

        System.out.println(new Date().getTime() - before.getTime());
    }   

}

Komentari IFs satu per satu. Berikut adalah dua perbandingan dari atas dalam byte-code yang dibongkar:

 21  getstatic EnumCompareSpeedTest$TestEnum.ONE : EnumCompareSpeedTest.TestEnum [19]
 24  getstatic EnumCompareSpeedTest$TestEnum.TWO : EnumCompareSpeedTest.TestEnum [25]
 27  invokevirtual EnumCompareSpeedTest$TestEnum.equals(java.lang.Object) : boolean [28]
 30  ifeq 36

 36  getstatic EnumCompareSpeedTest$TestEnum.ONE : EnumCompareSpeedTest.TestEnum [19]
 39  getstatic EnumCompareSpeedTest$TestEnum.TWO : EnumCompareSpeedTest.TestEnum [25]
 42  if_acmpne 48

Yang pertama (sama dengan) melakukan panggilan virtual dan menguji boolean kembali dari tumpukan. Yang kedua (==) membandingkan alamat objek secara langsung dari tumpukan. Dalam kasus pertama ada lebih banyak aktivitas.

Saya menjalankan tes ini beberapa kali dengan kedua IF satu per satu. "==" sedikit lebih cepat.


Saya menduga bahwa compiler-prediksi cabang mungkin membuat tes ini tidak valid. Kompiler yang pintar akan mengenali bahwa kedua pernyataan tersebut akan selalu bernilai false dan dengan demikian menghindari melakukan beberapa perbandingan. Kompiler yang sangat pintar bahkan mungkin mengenali bahwa nilai-nilai dalam loop y dan x tidak akan berpengaruh pada hasil dan mengoptimalkan seluruh hal ...
Darrel Hoffman

Itu bisa, tetapi jelas tidak. Saya menunjukkan bytecode yang dihasilkan oleh kompiler yang sebenarnya dalam jawaban saya.
ChrisCantrell

kalian berdua bingung. :-) Prediksi cabang berfungsi saat run-time sehingga kode byte yang berbeda tidak super relevan. Namun, dalam hal ini prediksi cabang akan membantu kedua kasus secara sama.
vidstige

7
Siapa peduli? Kecuali jika Anda membandingkan enum ribuan kali dalam satu loop selama video game, nanosecond tambahan tidak ada artinya.
user949300

Bytecode sangat tidak relevan untuk kinerja kecuali Anda memaksakan mode yang ditafsirkan. Tulis patokan JMH untuk melihat bahwa kinerjanya persis sama.
maaartinus


7

tl; dr

Pilihan lain adalah Objects.equalsmetode utilitas.

Objects.equals( thisEnum , thatEnum )

Objects.equals untuk null-safety

sama dengan operator == bukannya .equals ()

Operator mana yang harus saya gunakan?

Opsi ketiga adalah equalsmetode statis yang ditemukan pada Objectskelas utilitas yang ditambahkan ke Java 7 dan yang lebih baru.

Contoh

Berikut ini contoh menggunakan Monthenum.

boolean areEqual = Objects.equals( Month.FEBRUARY , Month.JUNE ) ;  // Returns `false`.

Manfaat

Saya menemukan beberapa manfaat untuk metode ini:

  • Tidak ada keamanan
  • Ringkas, mudah dibaca

Bagaimana itu bekerja

Logika apa yang digunakan Objects.equals?

Lihat sendiri, dari kode sumber Java 10 dari OpenJDK :

return (a == b) || (a != null && a.equals(b));

6

Menggunakan apa pun selain ==untuk membandingkan konstanta enum adalah omong kosong. Ini seperti membandingkan classobjek denganequals - jangan lakukan itu!

Namun, ada bug jahat (BugID 6277781 ) di Sun JDK 6u10 dan sebelumnya yang mungkin menarik karena alasan historis. Bug ini mencegah penggunaan yang tepat ==pada enum deserialized, meskipun ini bisa dibilang agak sudut kasus.


4

Enum adalah kelas yang mengembalikan satu instance (seperti lajang) untuk setiap konstanta enumerasi yang dideklarasikan oleh public static final field(immutable) sehingga ==operator dapat digunakan untuk memeriksa kesetaraan mereka daripada menggunakan equals()metode


1

Alasan enum bekerja dengan mudah dengan == adalah karena setiap instance yang didefinisikan juga merupakan singleton. Jadi perbandingan identitas menggunakan == akan selalu berhasil.

Tetapi menggunakan == karena ini bekerja dengan enums berarti semua kode Anda erat dengan penggunaan enum itu.

Misalnya: Enums dapat mengimplementasikan antarmuka. Misalkan Anda saat ini menggunakan enum yang mengimplementasikan Interface1. Jika nanti, seseorang mengubahnya atau memperkenalkan Impl1 kelas baru sebagai implementasi dari antarmuka yang sama. Kemudian, jika Anda mulai menggunakan instans Impl1, Anda akan memiliki banyak kode untuk diubah dan diuji karena penggunaan == sebelumnya.

Oleh karena itu, yang terbaik adalah mengikuti apa yang dianggap sebagai praktik yang baik kecuali jika ada keuntungan yang dapat dibenarkan.


Jawaban yang bagus, tetapi sudah disebutkan di sini .
shmosel

Um Pada titik itu, pertanyaannya adalah apakah Anda menggunakan == atau sama dengan pada antarmuka. Ditambah semua jenis pertanyaan tentang apakah benar-benar masuk akal untuk mengganti implementasi dari tipe yang tidak dapat diubah dengan implementasi yang dapat diubah. Dan mungkin bijaksana untuk mencari tahu apa praktik yang baik sebelum Anda khawatir tentang keuntungan yang bisa dibenarkan. (imho == adalah praktik yang lebih baik).
Robin Davies

1

Salah satu aturan Sonar adalah Enum values should be compared with "==". Alasannya adalah sebagai berikut:

Menguji kesetaraan nilai enum dengan equals()benar-benar valid karena enum adalah Obyek dan setiap pengembang Java tahu ==tidak boleh digunakan untuk membandingkan konten Obyek. Pada saat yang sama, menggunakan ==enum:

  • menyediakan perbandingan yang diharapkan (konten) dengan equals()

  • lebih aman dari nol equals()

  • menyediakan waktu kompilasi (statis) daripada memeriksa runtime

Untuk alasan ini, penggunaan ==harus lebih disukai equals().

Last but not least, ==pada enum bisa dibilang lebih mudah dibaca (kurang verbose) daripada equals().


0

Singkatnya, keduanya memiliki pro dan kontra.

Di satu sisi, ia memiliki kelebihan untuk digunakan ==, seperti yang dijelaskan dalam jawaban lain.

Di sisi lain, jika Anda dengan alasan apa pun mengganti enum dengan pendekatan yang berbeda (instance kelas normal), setelah menggunakan ==menggigit Anda. (BTDT.)


-1

Saya ingin melengkapi jawaban polygenelubricants:

Saya pribadi lebih suka sama dengan (). Tapi itu memeriksa kompatibilitas jenis. Yang menurut saya merupakan batasan penting.

Untuk melakukan pemeriksaan kompatibilitas jenis pada waktu kompilasi, deklarasikan dan gunakan fungsi kustom di enum Anda.

public boolean isEquals(enumVariable) // compare constant from left
public static boolean areEqual(enumVariable, enumVariable2) // compare two variable

Dengan ini, Anda mendapatkan semua keuntungan dari kedua solusi: perlindungan NPE, kode mudah dibaca dan ketik kompatibilitas kompatibilitas pada waktu kompilasi.

Saya juga merekomendasikan untuk menambahkan nilai UNDEFINED untuk enum.


4
Mengapa solusi ini lebih baik daripada ==? Dengan ==Anda mendapatkan perlindungan NPE, kode yang mudah dibaca, dan kompilasi pengecekan kompatibilitas jenis waktu, dan Anda mendapatkan semua itu tanpa menulis metode khusus yang sama dengan kustom.
Matt Ball

1
Sebuah UNDEFINEDnilai adalah mungkin ide yang baik. Tentu saja, di Java 8 Anda akan menggunakan Optionalgantinya.
Tomas
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.