Java paket adı sözleşmesi hatalı mı? [kapalı]

Etki alanı adını döndürme konusunda Java paket adı kurallarına hepimiz aşinayız. Yani www.evilcorp.com, sözleşmeye göre, java paketlerini almayı seçti com.evilcorp.stuff.

Giderek bıktım bundan bıktım. Ticari bir programcı olarak, bazı marka, satın alma veya benzeri şeylerden dolayı yazılım paketi adının tamamen ilgisiz olduğu konusunda tekrar tekrar karşılaşıyorum.

Açık kaynak dünyasında daha az isim değişikliği olduğundan mantıklı geliyor. Ancak bana öyle geliyor ki, pek çok (ticari / dahili) yazılımın raf ömrü, bunları yapan organizasyonunkinden çok daha uzun.

Sorun genellikle pazarlama departmanının kullandığı du jour ismini kullanmak için önderlik eden yazılım projeleri tarafından daha da kötüleşir . İmparatorun yeni kıyafetlerini yeni ve taze hissettirmek için başarısızlıkla çizginin 3 ayını değiştirecek bir isim.

Bu nedenle, çoğunlukla ters etki alanını paket adı olarak kullanmayı bıraktım. Bu büyük ölçüde yapılırsa, isim çarpışma riski vardır, ancak bu kesinlikle "benzersiz" yazılım adları kullanılarak, genel kelimelerden kaçınarak veya kütüphaneler olarak satılması / piyasaya sürülmesi planlanan projeler için ters etki alanı kullanılarak azaltılır. .

Diğer düşünceler?

Etki alanı adı sözleşmesine sahip olmayan Microsoft'un ad alanları (.NET paketleri) için vereceği tavsiyeyi teklif edeceğim . Bir alan adının sağlam ve kararlı bir kimliği temsil ettiğine inanmadığım için Java paketleri için de iyi bir tavsiye olduğunu düşünüyorum.

Bir ad alanı adı için genel biçim aşağıdaki gibidir:

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

Örneğin, Microsoft.WindowsMobile.DirectX.

Farklı şirketlerin ad alanlarının aynı ada ve ön eke sahip olmalarını önlemek için ad alanı adlarını şirket adıyla önekleyin.

Ad alanı adının ikinci düzeyinde kararlı, sürümden bağımsız bir ürün adı kullanın.

Kurumsal hiyerarşileri ad alanı hiyerarşilerindeki adların temeli olarak kullanmayın, çünkü şirketler içindeki grup adları kısa süreli olma eğilimindedir.

Ad alanı adı uzun ömürlü ve değişmeyen bir tanımlayıcıdır. Kuruluşlar geliştikçe, değişiklikler ad alanı adını eski yapmamalıdır.

Şirketinizin adı bile kararsızsa, sadece ürün adı ile başlamak isteyebilirsiniz.

Farklı bir problemin çözümüne bakıyorsunuz, yani programcı X ile programcı Y'nın aynı pakete dosya koyarak ayak parmaklarına adım atmasını nasıl önleriz?

"Etki alanı adınızı yalnızca ters çevirin" bunu zarif bir şekilde çözer, çünkü X ve Y'nin ilgisiz olması durumunda aynı paket ad alanını seçmeyeceklerinden oldukça eminiz.

Kongre hatalı değil. İnsanlar kendini güzelce gösterdiğin gibi kusurlu.

2 fayda düşünebilirim:

1. Bağımsız geliştiriciler arasındaki çarpışmayı önler. Bir etki alanı benzersizdir. İki kişi iki farklı projeyi aynı adlandırabilir, ancak bir etki alanının tam olarak bir sahibi vardır.
2. Bakıcıyı bulmayı kolaylaştırır. Bazı açık kaynaklı kitaplıkları kullanan bir kod tabanını devralırsanız, onu bulmanıza yardımcı olacak bir pakette olması daha iyi olur. Şimdiye kadar gerçekten önemli değil, çünkü kesinlikle kesinlikle google mümkün olacak. Ancak 10 yıl önce, bu çok belirgin değildi.

Ters etki alanı adı, farklı kuruluşların kitaplıklarında aynı sınıf adlarını kullanması durumunda ad çakışmalarını önlemek için kullanılmıştır. Basit bir çözümdür ve mahkeme dışında bazı dezavantajlara sahiptir (örneğin, aynı organizasyondaki sınıflar için isim çarpışmalarından ne haber)?

Kullanmak zorunda değilsiniz, bu bir kural değil, kuraldır. Örneğin, bazı Java programcıları Java Kod Sözleşmelerine saygı duymazlar .

Ancak alternatifleri düşünün. Örneğin, bir LogFactory için tam olarak nitelenmiş iki sınıf adı gibi:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

veya

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

Bu yüzden, düşüncelerime göre, sağduyunuzu ve kütüphanenizin kullanıcılarına yönelik bir düşünceyi içerdiği sürece dilediğinizi kullanın.

Yeni bir projeye başladığım zaman, pazarlama kaynaklarının sadece kaynak kodunda belirtildiği gibi, bilebilecekleri veya bilemeyebilecekleri içsel ve değiştirilemez bir isim konusunda her zaman ısrar ediyorum. Bu şekilde, proje adı değişiklikleri ve ad alanı kirliliği hakkında endişelenmeme gerek yok.

Bu senaryo bana uyar, çünkü kaynak kodu genellikle ürünün önemli bir parçası değildir, yani projeler genellikle kapalı kaynak kodlu bir sistemdir. Ancak, kaynak kodun ürün olduğu açık kaynaklı projelerde bu mümkün olmayabilir.