Jako słomianin rozważa pakiet java.util
, jest to wysypisko dla różnych klas, które w większości przypadków nie mają ze sobą nic wspólnego, oprócz osoby, która je tam leniwa lub nieinspirowana, aby wymyślić bardziej semantycznie poprawną nazwę pakietu dla swojej klasy.
Jako jeden przykład weźmy klasę, UUID
która byłaby semantycznie poprawną nazwą pakietu dla tej klasy?
Pracuję nad wdrożeniem własnej UUID
klasy, aby była bardziej lekka. Nie chcę używać me.myproject.util.UUID
nazwy mojego pakietu.
Rozważyłem, me.myproject.rfc4122.UUID
ale nie oznacza to semantycznego użycia UUID
.
Rozważyłem również, me.myproject.uuid.UUID
ale nie podoba mi się w tym tautologia, mimo że popularnym podejściem w Pythonie jest umieszczanie klasy w module o tej samej nazwie, a packages
w Javie nie są one semantycznie równoważne z modules
Pythonem.
Ja również rozważyć me.myproject.UUID
, ale odrzucił ją, bo nie chcą zanieczyszczać że część nazw z rzeczy, które nie są związane. To po prostu przenosi problem na wyższy poziom.
Rozważyłem również, me.myproject.lib.UUID
ale nie ma to większego znaczenia semantycznego .util
i tylko zmienia nazwę problemu.
semantics
: dziedzina językoznawstwa i logiki zajmująca się znaczeniem .
me.myproject.UUID
? Lubme.UUID
from me.myproject.uuid import UUID, GetUUIDInfo
wygląda OK. W module może znajdować się więcej niż jedna wyeksportowana rzecz.identity
lubidentifiers
umieścić swoje sugestie z trochę więcej wyjaśnień, jako odpowiedź będzie prawdopodobnie uzyskać przyjęta.Odpowiedzi:
Problem z próbą umieszczenia każdej klasy w pakiecie, który ma semantycznie poprawną nazwę dla tej klasy, polega na tym, że prowadzi ona do pakietów, które zawierają bardzo niewiele klas, a czasem nawet tylko jedną klasę. To z kolei prowadzi do wielu pakietów.
Bardziej pragmatycznym podejściem do nazewnictwa pakietów jest po prostu pomoc w znajdowaniu rzeczy. Przechowywanie często używanych rzeczy, które zawsze wiesz, gdzie znaleźć wszystkie zebrane w jednym miejscu, chroni je przed przeszkodami i dlatego ułatwia znajdowanie rzadszych rzeczy. Tak więc tak naprawdę nie potrzebujesz nazw pakietów, które są semantycznie poprawne dla każdej z zawartych w nich klas, potrzebujesz tylko nazw pakietów, które nie są semantycznie niepoprawne. Oczywiście nazwa pakietu „util” została wybrana zgodnie z tym tokiem myślenia: nie jest to semantycznie poprawna nazwa klas, które zawiera, ale nie jest również semantycznie niepoprawna i to wystarczy.
Jeśli więc ten typ UUID ma być używany tylko przez tę konkretną aplikację (o czym świadczy fakt, że planujesz umieścić go w „myproject”), to prawdopodobnie jest to część „modelu” twojego projekt. Powinieneś już mieć pakiet „modelowy”, zawierający zestaw wszystkich klas, które odpowiadają twoim trwałym bytom, z których wiele prawdopodobnie ma między nimi relacje, a UUID prawdopodobnie są środkiem do implementacji tych relacji. Ponadto twoje UUID prawdopodobnie wiedzą, jak się zachować, prawda? Ponadto twoje UUID można prawdopodobnie znaleźć tylko jako członków jednostek modelu, prawda? Tak więc pakiet modeli jest prawdopodobnie najlepszym miejscem na to.
W przeciwnym razie, jeśli tego typu UUID można użyć również w innych projektach, należy to postrzegać jako część jakiegoś frameworka. Może więc znajdować się w głównym folderze źródłowym tego frameworku lub w niektórych paczkach „typów”, jak sugeruje MainMa, a nawet w niektórych paczkach tego frameworku, zwanych „util” lub „misc”. Nic w tym złego.
źródło
Celem pakietów jest grupowanie klas według niektórych kryteriów (pakiet według typu / warstwy vs. pakiet według funkcji itp.). Naprawdę nie widzę sensu, aby tworzyć pakiet tylko dla jednej klasy - zwłaszcza jeśli nie spodziewasz się, że w przyszłości będą w nim inne klasy.
Myślę też, że nazwa pakietu „util” nie jest całkowicie bez znaczenia - po prostu grupuje klasy według określonych kryteriów - dla mnie klasa „util” oznacza, że nie należy ona do domeny aplikacji, ale nie jest też częścią framework (nie wpływa na strukturę aplikacji). Jest to po prostu rozszerzenie (niestandardowej) biblioteki.
W takim przypadku nie miałbym problemu z umieszczeniem tej klasy UUID w pakiecie „util”. Jeśli będą jakieś inne klasy narzędzi związane z UUID (takie jak osobna klasa do generowania UUID), łatwo je refaktoryzować i stworzyć dla nich pakiet „util.uuid” (chyba że tworzysz bibliotekę, a UUID będzie częścią odsłoniętego interfejsu , musisz być trochę „przyszłościowy”).
źródło
Wujek Bob ma kilka wskazówek dotyczących rozdzielania paczek.
Pierwsze trzy zasady dotyczące pakietów dotyczą spójności pakietów, mówią nam, co umieścić w paczkach:
Tak więc, odpowiadając na twoje pytanie, kto / co będzie używał klasy UUID, masz ją jako atrybut lub wywołuje w niej operacje? Jak wygląda twój wykres zależności ? UUID będzie używany wraz z innymi klasami ?
W zależności od odpowiedzi, być może należy nazwać to me.myproject.identity opakowaniu, me.myproject.serialization pakiet, me.myproject. DTO, a nawet coś zupełnie innego. Być może klasa UUID powinna być trzymana razem z twoimi modelami, a ty umieścisz ją w pakiecie, który już masz, na przykład me.myproject.models .
źródło
dto
jest prawie tak semantycznie bezużyteczny jaklib
lubutils
, caładto
koncepcja jest naiwnym anty-wzorem z połowy lat 90.,model
należy również do tej samej bezużytecznej kategorii uogólnieniaPo pierwsze, UUID (z dużymi literami) wydaje mi się bardzo złym pomysłem na nazwę pakietu lub nazwę klasy, ze wszystkich stylów wymuszonych w taki czy inny sposób wszystkie nazwy wielkich liter są powiązane z „stałymi”. Pakiety służą do organizowania rzeczy, najłatwiejszym sposobem nazwania paczki jest wartość klas, które ona zawiera:
com.example.identifier
;com.example.uuid
.Utrzymaj prostotę IT
źródło
java.util.UUID
,java.net.URL
,java.util.zip.CRC32
, itd.java.util.zip.GZIPOutputStream
klasą?GZIP
oznacza ...? there is also a
java.util.zip.ZipOutputStream`UUID
jest wielkie litery.