it-swarm-id.com

Apakah konvensi nama paket Java salah?

Kita semua terbiasa dengan konvensi nama paket Java untuk mengubah nama domain. Ya www.evilcorp.com Akan, menurut konvensi, memilih untuk memiliki Java paket com.evilcorp.stuff.

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

Di dunia opensource, ada sedikit perubahan nama sehingga 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 perangkat lunak yang mengambil pimpinan departemen pemasaran untuk menggunakan nama du jour yang mereka gunakan merujuk ke 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?

28
Martin Algesten

Saya akan mengutip saran yang diberikan Microsoft untuk namespaces (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.

23
Allon Guralnek

Anda melihat 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.

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

15
user1249

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

Saya dapat memikirkan 2 manfaat:

  1. Ini menghindari tabrakan antara pengembang independen. Domain unik. Dua orang dapat menyebutkan dua proyek berbeda yang sama, tetapi satu domain memiliki tepat satu pemilik.
  2. 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.
10
back2dos

Nama domain terbalik digunakan untuk menghindari tabrakan nama jika organisasi yang berbeda menggunakan nama kelas yang sama di perpustakaan mereka. Ini adalah solusi sederhana dan off cource memiliki beberapa kekurangan (mis. 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 Java programmer 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 bagi pengguna perpustakaan Anda.

7
user7197

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, mis. Proyek biasanya merupakan sumber tertutup, sistem berpemilik. Namun, dalam proyek sumber terbuka di mana kode sumbernya adalah produk, ini mungkin tidak layak.

4
SWeko