Czy konwencja nazwy pakietu Java jest wadliwa? [Zamknięte]

Wszyscy znamy konwencję nazewnictwa nazw pakietów Java. Tj. www.evilcorp.com, Zgodnie z konwencją, wolałby mieć swoje pakiety Java com.evilcorp.stuff.

Coraz bardziej mam tego dość. Jako programista komercyjny ciągle napotykam, że nazwa pakietu oprogramowania jest całkowicie nieistotna z powodu zmiany marki, nabycia lub podobnego.

W świecie open source jest mniej zmian nazw, więc ma to sens. Wydaje mi się jednak, że okres trwałości wielu programów (komercyjnych / wewnętrznych) jest znacznie dłuższy niż czas ich produkcji.

Problem często się pogłębia, gdy projekty oprogramowania podejmują decyzję działu marketingu, by używać nazwy du Jour, której używają, odnosi się do określonego projektu. Nazwa, która bez wątpienia zmieni 3 miesiące później, aby nowe ubrania cesarza wydawały się świeże i nowe.

Z tego powodu najczęściej przestałem używać odwrotnej domeny jako nazwy pakietu. To prawda, że ​​jeśli odbywa się to na dużą skalę, istnieje ryzyko kolizji nazw, ale na pewno można to złagodzić, stosując albo „unikalne” nazwy oprogramowania, unikając słów ogólnych, albo wykorzystując domenę odwrotną do projektów przeznaczonych do sprzedaży / wydania jako biblioteki .

Inne przemyślenia?

Przytoczę radę Microsoft dotyczącą przestrzeni nazw (pakietów .NET), która nie ma konwencji nazw domen. Myślę, że to dobra rada także dla pakietów Java, ponieważ nie wierzę, że nazwa domeny reprezentuje solidną i stabilną tożsamość.

Ogólny format nazwy przestrzeni nazw jest następujący:

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

Na przykład Microsoft.WindowsMobile.DirectX.

Wykonaj prefiks nazw przestrzeni nazw z nazwą firmy, aby przestrzenie nazw różnych firm nie miały tej samej nazwy i prefiksu.

Używaj stabilnej, niezależnej od wersji nazwy produktu na drugim poziomie nazwy przestrzeni nazw.

Nie używaj hierarchii organizacyjnych jako podstawy nazw w hierarchiach przestrzeni nazw, ponieważ nazwy grup w korporacjach są zazwyczaj krótkotrwałe.

Nazwa przestrzeni nazw jest długowiecznym i niezmiennym identyfikatorem. W miarę ewolucji organizacji zmiany nie powinny powodować, że nazwa przestrzeni nazw staje się przestarzała.

Jeśli nawet nazwa Twojej firmy jest niestabilna, możesz zacząć od nazwy produktu.

Patrzysz na rozwiązanie innego problemu, mianowicie jak uniknąć tego, aby programista X i programista Y stawiali sobie nawzajem palce, umieszczając pliki w tym samym pakiecie.

„Po prostu odwróć nazwę swojej domeny” rozwiązuje to w elegancki sposób, ponieważ jesteś pewien, że jeśli X i Y nie są ze sobą powiązane, nie wybiorą tej samej przestrzeni nazw pakietów.

Konwencja nie jest wadliwa. Ludzie mają wady, jak dobrze się zilustrowałeś.

Mogę wymyślić 2 korzyści:

1. Pozwala to uniknąć kolizji między niezależnymi programistami. Domena jest unikalna. Dwie osoby mogą nazwać dwa różne projekty tak samo, ale domena ma dokładnie jednego właściciela.
2. Ułatwia to znalezienie opiekuna. Jeśli odziedziczysz bazę kodu, która korzysta z biblioteki typu open source, lepiej umieść ją w pakiecie, który pomoże ci ją znaleźć. Do tej pory nie ma to większego znaczenia, ponieważ z pewnością będziesz mógł google google. Ale 10 lat temu nie było to tak oczywiste.

Odwrócona nazwa domeny została użyta, aby uniknąć kolizji nazw w przypadku, gdy różne organizacje używają tych samych nazw klas w swoich bibliotekach. Jest to proste rozwiązanie i off-cource ma pewne wady (np. Co z kolizjami nazw dla klas w tej samej organizacji?).

Nie musisz go używać, jest to konwencja, a nie zasada „zrób lub umrzyj”. Na przykład niektórzy programiści Java nie przestrzegają konwencji Java Code .

Ale rozważ alternatywy. Jak na przykład chciałbyś otrzymać dwie w pełni kwalifikowane nazwy klas dla LogFactory:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

lub

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

Tak więc, moim zdaniem, używaj tego, co chcesz, pod warunkiem, że obejmuje to zdrowy rozsądek i uwagę dla użytkowników twojej biblioteki.

Kiedy rozpoczynam nowy projekt, zawsze nalegam na wewnętrzną i niezmienną nazwę, którą marketingowcy mogą znać lub nie, ponieważ będzie o niej mowa tylko w kodzie źródłowym. W ten sposób nie muszę się martwić o zmiany nazw projektów i zanieczyszczenie przestrzeni nazw.

Ten scenariusz jest dla mnie odpowiedni, ponieważ kod źródłowy zwykle nie jest ważną częścią produktu, tzn. Projekty są zwykle zamkniętymi źródłowymi, zastrzeżonymi systemami. Jednak w projektach typu open source, w których kod źródłowy jest produktem, może to nie być możliwe.