Apakah konvensi nama paket Java cacat? [Tutup]

28

Kita semua akrab dengan konvensi nama paket Java untuk mengubah nama domain. Yaitu www.evilcorp.com, dengan konvensi, memilih untuk memiliki paket java mereka com.evilcorp.stuff.

Semakin saya muak dengan ini. Sebagai seorang programmer komersial, saya menemukan berkali-kali bahwa nama paket perangkat lunak sama sekali tidak relevan karena beberapa mengubah citra, akuisisi atau serupa.

Di dunia opensource ada sedikit perubahan nama jadi itu masuk akal. Namun menurut saya umur simpan banyak perangkat lunak (komersial / internal) jauh lebih lama daripada yang dibuat oleh organisasi.

Masalahnya sering diperburuk oleh proyek-proyek perangkat lunak yang mengambil pimpinan departemen pemasaran untuk menggunakan nama du jour yang mereka gunakan merujuk pada proyek tertentu. Sebuah nama yang, tanpa gagal, akan berubah 3 bulan ke depan untuk membuat pakaian baru sang kaisar terasa segar dan baru.

Karena itu, saya sering berhenti menggunakan domain terbalik sebagai nama paket. Memang, jika ini dilakukan dalam skala besar, ada risiko tabrakan nama, tetapi pasti ini dikurangi dengan menggunakan nama perangkat lunak "unik", menghindari kata-kata umum, atau menggunakan domain terbalik untuk proyek yang dimaksudkan untuk dijual / dirilis sebagai perpustakaan. .

Pikiran lain?

java naming

— Martin Algesten
sumber

2

We're all familiar with the Java package name convention of turning the domain name around.- um..tidak kita bukan ... :)

— dr Hannibal Lecter

8

@dr Hannibal Lecter: Cukup sederhana. Java (di situs Java.com) memberi nama paket mereka com.java.etc.etc. Apache (di situs Apache.org) memberi nama paket mereka org.apache.etc.etc. Anda melihat polanya.

— doppelgreener

3

@dr Hannibal Lecter: Cf. docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

— user359996

1

"Di dunia opensource ada sedikit perubahan nama" - bahkan ada masalah, sering saya melihat proyek yang sekarang di katakan github tetapi nama paket mereka mengungkapkan bahwa mereka dulu kebalikan dari net.sourceforge.xxx atau com. googlecode.xxx

— nafg

@nafg - benar. inilah sebabnya saya cenderung mendaftarkan nama domain saya sendiri untuk proyek open source apa pun yang saya mulai kerjakan hari ini, karena saya tidak selalu ingin mengikat identitasnya dengan beberapa perusahaan tertentu (apakah itu seperti sourceforge atau github yang menyediakannya dengan layanan, atau yang seperti perusahaan saya sendiri yang memberikan motivasi asli untuk mengembangkannya). Perlu bebas untuk menjadi miliknya sendiri.

— Jules

23

Saya akan mengutip saran yang diberikan Microsoft untuk ruang nama (paket .NET), yang tidak memiliki konvensi nama domain. Saya pikir itu saran yang baik untuk paket Java juga, karena saya tidak percaya bahwa nama domain mewakili identitas yang solid dan stabil.

Format umum untuk nama namespace adalah sebagai berikut:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

Sebagai contoh Microsoft.WindowsMobile.DirectX,.

Lakukan awalan namespace nama dengan nama perusahaan untuk mencegah ruang nama dari perusahaan yang berbeda memiliki nama dan awalan yang sama.

Gunakan nama produk versi-independen yang stabil di tingkat kedua nama namespace.

Jangan gunakan hierarki organisasi sebagai dasar untuk nama dalam hierarki namespace, karena nama grup dalam perusahaan cenderung berumur pendek.

Nama namespace adalah pengidentifikasi berumur panjang dan tidak berubah. Saat organisasi berkembang, perubahan tidak boleh membuat nama namespace menjadi usang.

Jika bahkan nama perusahaan Anda tidak stabil, Anda mungkin ingin memulai dengan nama produk.

— Allon Guralnek
sumber

3

Apa yang Microsoft sarankan untuk Anda lakukan jika perusahaan lain memiliki nama yang sama dengan Anda?

25

@ Thorbjørn - litigasi

— RevBingo

9

@ Thorbjørn: Namespace, tidak seperti domain, tidak, dan tidak dapat dimiliki oleh siapa pun. Ini hanya pembagian logis atau kategorisasi kode. Peluang tabrakan antara Anda dan perusahaan lain mendekati nol, kecuali jika perusahaan lain itu juga mengembangkan perangkat lunak, dalam teknologi yang sama, dan memiliki penawaran serupa (singkatnya - pesaing Anda). Dalam hal ini, saya akan menerima saran RebBingo, kecuali Anda baik-baik saja dengan memiliki perusahaan pesaing yang memiliki nama yang sama dengan perusahaan Anda.

— Allon Guralnek

4

Seperti yang ditunjukkan dalam jawaban @ Thorbjørn, masalah yang dipecahkan oleh konvensi penamaan Java tidak menjamin keajegan tetapi lebih menjamin keunikan . Perhatikan bahwa konvensi Microsoft tidak menjamin .

— user359996

4

@ user359996: Seperti yang saya katakan, saya tidak melihat mengapa keunikan universal adalah masalah yang perlu dipecahkan. Mengapa Anda memerlukan nama untuk menjadi unik di basis kode yang saling eksklusif? Dan gaya Java tidak menjaminnya , karena kepemilikan nama domain dapat berpindah tangan. Pengembang yang memiliki jUtils.com dapat mengembangkan perpustakaan com.jutils. * Yang banyak digunakan, dan kemudian menjual domainnya ke pengembang yang sama sekali berbeda yang mengembangkan perpustakaan com.jutils. * Yang berbeda yang juga populer, tetapi bertabrakan dengan perpustakaan yang ada.

— Allon Guralnek

15

Anda mencari solusi untuk masalah yang berbeda, yaitu bagaimana kita menghindari programmer X dan programmer Y saling menginjak jari kaki dengan meletakkan file dalam paket yang sama.

"Just reverse your domain name" selesaikan ini dengan cara yang elegan, karena Anda cukup yakin bahwa jika X dan Y tidak terkait, mereka tidak akan memilih ruang nama paket yang sama.

+1 "Anda mencari solusi untuk masalah yang berbeda."

— user359996

10

Konvensi ini tidak cacat. Orang-orang cacat, seperti yang telah Anda gambarkan dengan baik.

Saya dapat memikirkan 2 manfaat:

Ini menghindari tabrakan antara pengembang independen. Domain unik. Dua orang dapat menyebutkan dua proyek berbeda dengan yang sama, tetapi satu domain memiliki tepat satu pemilik.
Itu membuatnya lebih mudah untuk menemukan pengelola. Jika Anda mewarisi basis kode, yang menggunakan beberapa pustaka sumber terbuka, lebih baik berada dalam paket yang membantu Anda menemukannya. Sekarang ini tidak terlalu penting, karena Anda pasti akan dapat mencarinya di Google. Tetapi 10 tahun yang lalu, ini tidak begitu jelas.

— back2dos
sumber

7

Nama domain terbalik digunakan untuk menghindari benturan nama jika organisasi yang berbeda menggunakan nama kelas yang sama di perpustakaan mereka. Ini adalah solusi yang sederhana dan off cource memiliki beberapa kekurangan (misalnya bagaimana dengan tabrakan nama untuk kelas di organisasi yang sama?).

Anda tidak diwajibkan untuk menggunakannya, itu adalah konvensi bukan aturan do or die. Sebagai contoh, beberapa programmer Java tidak menghormati Konvensi Kode Java .

Tetapi pertimbangkan alternatifnya. Bagaimana Anda, misalnya, menyukai dua nama kelas yang sepenuhnya memenuhi syarat untuk LogFactory:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

atau

org.apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

Jadi, menurut saya, gunakan apa pun yang Anda suka asalkan termasuk akal sehat dan pertimbangan untuk pengguna perpustakaan Anda.

4

Ketika saya memulai proyek baru, saya selalu menekankan nama internal dan tidak dapat diubah yang mungkin atau tidak diketahui oleh orang-orang pemasaran, karena hanya akan disebut dalam kode sumber. Dengan begitu, saya tidak perlu khawatir tentang perubahan nama proyek dan polusi namespace.

Skenario ini cocok untuk saya, karena kode sumber biasanya bukan merupakan bagian penting dari produk, yaitu proyek biasanya merupakan sumber tertutup, sistem berpemilik. Namun, dalam proyek open-source di mana kode sumbernya adalah produk, ini mungkin tidak layak.

— SWeko
sumber