Semantycznie bardziej odpowiednia nazwa pakietu niż `util` dla następujących rzeczy?

18

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ę, UUIDktóra byłaby semantycznie poprawną nazwą pakietu dla tej klasy?

Pracuję nad wdrożeniem własnej UUIDklasy, aby była bardziej lekka. Nie chcę używać me.myproject.util.UUIDnazwy mojego pakietu.

Rozważyłem, me.myproject.rfc4122.UUIDale nie oznacza to semantycznego użycia UUID.

Rozważyłem również, me.myproject.uuid.UUIDale nie podoba mi się w tym tautologia, mimo że popularnym podejściem w Pythonie jest umieszczanie klasy w module o tej samej nazwie, a packagesw Javie nie są one semantycznie równoważne z modulesPythonem.

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.UUIDale nie ma to większego znaczenia semantycznego .utili tylko zmienia nazwę problemu.

semantics: dziedzina językoznawstwa i logiki zajmująca się znaczeniem .


źródło
Jak o me.myproject.UUID? Lubme.UUID
Robert Harvey
Dla mnie coś w stylu from me.myproject.uuid import UUID, GetUUIDInfowygląda OK. W module może znajdować się więcej niż jedna wyeksportowana rzecz.
9000
2
JXTA ma pakiety „id” do rzeczy związanych z identyfikatorami.
greg-449
@ grzegorz-449 - jestem pochylony w kierunku identitylub identifiersumieścić swoje sugestie z trochę więcej wyjaśnień, jako odpowiedź będzie prawdopodobnie uzyskać przyjęta.

Odpowiedzi:

11

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.

Mike Nakis
źródło
2
Spróbuj ograniczyć komentarz w odpowiedziach, które tak naprawdę nie zwiększają użyteczności odpowiedzi. Sekcja komentarzy jest zarezerwowana dla takich zastrzeżeń. Dziękuję Ci.
wałek klonowy
1

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”).

qbd
źródło
1
To jest moje podejście. Nie ma sensu tworzyć pakietów, które nie mają wyraźnego celu. Jeśli klasy nie można łatwo przypisać do znaczącego pakietu, wówczas „util” jest w porządku, a może nawet preferowane. Zwykle dzieje się to w miarę upływu czasu, gdy wystarczająca liczba klas kończy się w util, które są ze sobą powiązane i można je łatwo refaktoryzować (przynajmniej podczas programowania) do znaczących pakietów. Jeśli próbujesz stworzyć unikalne pakiety dla każdej klasy, której nie wiesz, dokąd zmierza, możesz łatwo ominąć te relacje i możliwość przekształcenia się w czystszą architekturę.
Dunk
@Dunk, to właściwie bardzo dobra uwaga - przedwczesne tworzenie nieco sztucznej struktury pakietu zapobiegnie lepszej, bardziej naturalnej organizacji po drodze.
qbd
1

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:

  1. Granulat ponownego użycia stanowi granulat uwalniania
  2. Klasy, które zmieniają się razem, są pakowane razem
  3. Klasy używane razem są pakowane razem

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 .

Hbas
źródło
1
dtojest prawie tak semantycznie bezużyteczny jak liblub utils, cała dtokoncepcja jest naiwnym anty-wzorem z połowy lat 90., modelnależy również do tej samej bezużytecznej kategorii uogólnienia
Nie wiemy wystarczająco dużo o twoim projekcie, aby dać ci więcej użytecznych nazw
Hbas
-2

Po 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:

  • możesz na przykład oddzielić klasy według ich wartości biznesowej com.example.identifier;
  • lub na przykład przez ich wartość techniczną com.example.uuid.

Utrzymaj prostotę IT

Tiberiu C.
źródło
2
Przykłady klas ALLCAPS w Javie: java.util.UUID, java.net.URL, java.util.zip.CRC32, itd.
scriptin
@scriptin Czy programiści nie byliby łatwiejsi, gdyby potrafił odróżnić styl od kapsli klasą od „stałej”, członka od nazwy pakietu i tak dalej? Jak myślisz, dlaczego CRC32, UUID to dobra nazwa dla klasy, tylko dlatego, że java to zrobiła? Lub ponieważ jest to akronim od „Uniwersalnie unikalny identyfikator” lub „cykliczna kontrola nadmiarowości” ... ale poczekaj chwilę! Co jest z tą java.util.zip.GZIPOutputStreamklasą? GZIPoznacza ... ? there is also a java.util.zip.ZipOutputStream`
Tiberiu C.
1
Klasy są typami, stałe są wartościami, nie ma zamieszania. Nie sądzę, aby te nazwy były dobre lub złe, po prostu zwracam uwagę, że style (kodowanie), o których mówisz, nie zmuszają klas do posiadania małych liter. W Pythonie też UUIDjest wielkie litery.
scriptin
Jeśli widzisz / zachowujesz kod na co dzień, jego styl różnicuje między fiestą „łatwą do odczytania” a fiestą „cofnij i naprzód”, izolując się tutaj tylko do stylu wielkich liter, myślę, że bardziej wartościowe jest wyrażanie poprzez czapki, typ elementu (klasa, stała, pakiet itp.) niż fakt, że jest to akronim.
Tiberiu C.,
1
Pierwotne pytanie nie miało nic wspólnego z tym, jakiej litery należy użyć podczas pisania nazwy pakietu. Semantycznie UUID nie różni się niczym od Uuid, Uuid, UuId, UuID lub jakiegokolwiek innego dowolnego schematu wielkich liter, który uważasz za „najlepszy”.
Brandin