Niedawno oglądałem aplikację Java, która miała bardzo drobną strukturę pakietu. Wiele pakietów zawierało tylko jedną lub dwie klasy i wiele pakietów podrzędnych. Również wiele pakietów zawierało więcej pakietów podrzędnych niż rzeczywiste klasy.Czy drobna struktura paczki jest dobra czy zła?
Czy to jest dobre czy złe?
IMO, to zła rzecz, choć nie jest prawdziwym ograniczeniem w zakresie konserwacji.
Wadą jest to, że sprawia, że klasy trudniej znaleźć, i że sprawia, że nazwy pakietów są bardziej szczegółowe. Ten pierwszy dotyczy więcej, gdy nie używasz IDE.
Można argumentować, że ułatwia modularyzację w połączeniu z określeniem "pakiet prywatny". Ale na odwrót, można również twierdzić, że nadmierne upakowanie rzeczywiście ma coś przeciwnego; tj. zmuszanie Cię do używania public, gdzie nie musiałbyś, gdybyś był mniej drobnoziarnisty/pedantyczny.
To oczywiście subiektywne, ale ja na ogół wolę decydować o moich pakietach w taki sposób, aby zawierały co najmniej 3-4 klasy, ale nie więcej niż 13-15. Poprawia zrozumienie, nie zakłócając projektu. Dla innych może być inaczej. W przypadku, gdy paczka powiększa się o więcej niż 13-15 klas, wymagany jest pakiet podpakietowy.
Myślę, że drobniejsza struktura paczki jest dobra. Głównym powodem jest to, że może pomóc zminimalizować zależności. Ale bądź ostrożny ... jeśli zepsujesz rzeczy, które tak naprawdę należą do siebie, skończysz z zależnościami cyklicznymi!
Zgodnie z ogólną zasadą zazwyczaj mam interfejs (lub grupę powiązanych interfejsów) w pakiecie. W podpakietach będę miał implementacje tych interfejsów (zamiast wszystkich implementacji w tym samym pakiecie). W ten sposób klient może po prostu polegać na interfejsie i realizacji zainteresowania ... i nie wszystkie inne rzeczy, których nie potrzebują.
Mam nadzieję, że to pomoże.
Rzeczywista liczba typów, które kończą się w jednej konkretnej paczce, nie jest taka ważna. W ten sposób dochodzisz do swojej struktury paczki.
Rzeczy takie jak abstrakcja ("co" zamiast "jak", w zasadzie "publiczne" API), sprzężenie (stopień uzależnienia pakietu od innych pakietów) i spójność (jak powiązana jest funkcjonalność w jednym pakiecie) są ważniejsze.
Niektóre wskazówki projektowania opakowania (głównie Uncle Bob) są na przykład:
Nie próbuj odtłuszczać całej struktury paczki od zera (nie będziesz tego potrzebować). Zamiast tego niech ewoluuje i często się rozwija. Zajrzyj do sekcji import źródeł Java, aby uzyskać inspirację do przenoszenia typów.Nie rozpraszaj się pakietami zawierającymi tylko jeden lub kilka typów.
Pisząc od zera moją drogą jest rozpoczęcie wszystkich zajęć w pakiecie głównym (com.example.app1). Kiedy istnieje pewna liczba powiązanych ze sobą klas, które "wykonują całą rzecz", jest czas na stworzenie pakietu. Po pewnym czasie tworzenie klas pomocniczych może zostać przeniesione do ogólnego pakietu (np. Com.example.app1.misc, com.example.app1.utils) w celu wyładowania pakietu głównego.
Staram się więc zachować pakiet root.
Drobnoziarniste nie jest złe, ale jak powiedziane często refaktoryzacja daje kompaktową strukturę opakowania.
Opakowanie to jednostka enkapsulacji.
Idealnie eksponuje publiczny interfejs API za pośrednictwem interfejsu (interfejsów) i ukrywa szczegóły implementacji w prywatnych klasach pakietów.
Wielkość paczki jest zatem liczbą klas potrzebnych do wdrożenia publicznego interfejsu API.
Istnieje również magiczna liczba 7 +/- 2. W obrębie kręgów fizjologicznych pokazano, że jest to podstawowy limit naszej zdolności do zrozumienia danego zestawu rzeczy. Ile możemy zatrzymać w pamięci krótkoterminowej i przetwarzać w tym samym czasie, zanim nasze mózgi zaczną się wymieniać. Nie jest to zła reguła, którą odkryłem podczas kodowania, tzn. Gdy pakiet zaczyna być większy niż 10 klas, czas pomyśleć poważnie o podzieleniu go, ale poniżej 5 pakietów naprawdę nie jest tego wart. Odnosi się również do takich rzeczy jak organizacja menu. Zobacz Millers paper lub google.