it-swarm-eu.dev

Je chybná konvence Java název balíčku v balíčku)?

Všichni jsme obeznámeni s konvencí názvu balíčku Java), jak otočit název domény. I.e. www.evilcorp.com by se konvenčně rozhodlo mít své Java balíčky com.evilcorp.stuff.

Stále mě to trápí. Jako komerční programátor se znovu a znovu setkávám s tím, že název softwarového balíčku je zcela irelevantní kvůli nějakému rebrandu, akvizici nebo podobně.

Ve světě opensource existuje méně změn názvů, takže to dává smysl. Zdá se mi však, že doba skladování mnoha kusů (komerčního/interního) softwaru je mnohem delší než životnost organizace, která je vyrábí.

Problém je často ještě horší softwarovými projekty, které vedou marketingové oddělení k použití názvu du jour, které používají, odkazují na určitý projekt. Jméno, které se beze zbytku změní o 3 měsíce dolů, aby se císařovy nové šaty cítily svěží a nové.

Z tohoto důvodu jsem většinou přestal používat reverzní doménu jako název balíčku. Je pravda, že pokud se tak děje ve velkém měřítku, existuje riziko kolizí jmen, ale to je jistě zmírněno buď použitím „jedinečných“ softwarových jmen, vyhýbáním se obecným slovům, nebo použitím reverzní domény pro projekty, které mají být prodávány/vydávány jako knihovny .

Jiné myšlenky?

28
Martin Algesten

Budu citovat rada, kterou Microsoft dává pro namespaces (.NET's balíčky), která nemá konvenci názvů domén. Myslím, že je to dobrá rada pro balíčky Java), protože si nemyslím, že doménové jméno představuje solidní a stabilní identitu.

Obecný formát názvu oboru názvů je následující:

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

Například, Microsoft.WindowsMobile.DirectX.

Proveďte názvy předpon jmenného prostoru s názvem společnosti, abyste zabránili jmenným prostorům různých společností mít stejný název a předponu.

Do druhé úrovně názvu oboru názvů použijte stabilní název produktu nezávislý na verzi.

Nepoužívejte organizační hierarchie jako základ pro jména v hierarchiích oboru názvů, protože názvy skupin v korporacích bývají krátkodobé.

Název oboru názvů je dlouhodobý a neměnný identifikátor. Jak se organizace vyvíjejí, změny by neměly zastarat název oboru názvů.

Pokud je i název vaší společnosti nestabilní, možná budete chtít začít s názvem produktu.

23
Allon Guralnek

Díváte se na řešení jiného problému, konkrétně jak se vyhneme tomu, že programátor X a programátor Y krokují na ostatních prstech tím, že ukládají soubory do stejného balíčku.

„Prostě obráťte své doménové jméno“ to vyřešte elegantním způsobem, protože jste si jisti, že pokud X a Y nejsou ve spojení, nevyberou stejný prostor pro název balíčku.

15
user1249

Úmluva není chybná. Lidé jsou chybní, jak jste se pěkně ilustrovali.

Dokážu vymyslet 2 výhody:

  1. Zabraňuje kolizi mezi nezávislými vývojáři. Doména je jedinečná. Dva lidé mohou pojmenovat dva různé projekty stejně, ale doména má přesně jednoho vlastníka.
  2. Usnadňuje nalezení správce. Pokud zdědíte kódovou základnu, která používá nějakou knihovnu s otevřeným zdrojovým kódem, je lepší být v balíčku, který vám ji pomůže najít. V tuto chvíli to opravdu nezáleží, protože to určitě budete moci google. Ale před 10 lety to nebylo tak zřejmé.
10
back2dos

Název reverzní domény byl použit k zamezení kolizí názvů v případě, že různé organizace používají ve svých knihovnách stejné názvy tříd. Je to jednoduché řešení a off cource má některé nevýhody (např. Co kolize jmen pro třídy ve stejné organizaci?).

Nejste povinni jej používat, jedná se o konvence, nikoli pravidlo do nebo die. Například někteří Java programátoři nerespektují Java Code Conventions ).

Ale zvažte alternativy. Jak byste například chtěli dva plně kvalifikované názvy tříd pro LogFactory:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

nebo

org.Apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

Takže podle mých myšlenek používejte, co se vám líbí, pokud to zahrnuje zdravý rozum a ohled na uživatele vaší knihovny.

7
user7197

Když zahajuji nový projekt, vždy trvám na interním a neměnném jménu, které marketingoví lidé mohou nebo nemusí vědět, protože to bude uvedeno pouze ve zdrojovém kódu. Tímto způsobem se nemusím obávat změn názvu projektu a znečištění jmenného prostoru.

Tento scénář se mi hodí, protože zdrojový kód není obvykle důležitou součástí produktu, tj. Projekty jsou obvykle uzavřeným zdrojovým proprietárním systémem. U projektů s otevřeným zdrojovým kódem, kde je zdrojovým kódem produkt, však toto nemusí být proveditelné.

4
SWeko