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

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 .

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.

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

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 .

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