Czy istnieją najlepsze praktyki organizacji pakietów (Java)? [zamknięte]

Organizuję Pakiety według funkcji, a nie według wzorców czy ról implementacji. Myślę, że pakiety takie jak:

• beans
• factories
• collections

Są w błędzie.

Wolę, na przykład:

• orders
• store
• reports

Więc mogę ukryć szczegóły implementacji poprzez widoczność pakietu. Fabryka zamówień powinna znajdować się w opakowaniu orders, więc szczegóły dotyczące tworzenia zamówienia są Ukryty.

Krótka odpowiedź: jeden pakiet na moduł/funkcję, ewentualnie z pod-pakietami. Umieść ściśle powiązane rzeczy w jednym opakowaniu. Unikaj kolistych zależności między pakietami.

Długa odpowiedź: zgadzam się z większością tego artykułu

Preferuję funkcję przed warstwami, ale to chyba zależy od Twojego projektu. Rozważ swoje siły:

• zależności
  Spróbuj zminimalizować zależności pakietów, zwłaszcza między funkcjami. W razie potrzeby wyodrębnij interfejsy API.
• Organizacja zespołu
  W niektórych organizacjach zespoły pracują nad funkcjami, a w innych nad warstwami. Wpływa to na sposób organizacji kodu, użycie go do sformalizowania interfejsów API lub zachęcanie do współpracy.
• rozmieszczenia i wersjonowanie
  Umieszczenie wszystkiego w module sprawia, że wdrażanie i wersjonowanie prostsze, ale trudniejsze naprawianie błędów. Dzielenie rzeczy umożliwia lepsze Kontrola, skalowalność i dostępność.
• Odpowiedz na zmianę
  Dobrze zorganizowany kod jest dużo prostszy do zmiany niż wielka kula błota.
• Rozmiar (Ludzie i linie kodu)
  Im większy, tym bardziej sformalizowany / ustandaryzowany musi być.
• Znaczenie / jakość
  Jakiś kod jest ważniejszy niż inne. Interfejsy API powinny być bardziej stabilne niż implementacja. Dlatego też należy je wyraźnie rozdzielić.
• poziom abstrakcji i punkt wejścia
  Osoba z zewnątrz powinna wiedzieć, o co chodzi w kodzie i od czego zacząć czytanie, patrząc na drzewo pakietów.

Przykład:

com/company/module
  + feature1/
    - MainClass          // The entry point for exploring
    + api/               // Public interface, used by other features
    + domain/
      - AggregateRoot
      + api/             // Internal API, complements the public, used by web
      + impl/ 
    + persistence/       
    + web/               // presentation layer 
    + services/          // Rest or other remote API 
    + support/            
  + feature2/
  + support/             // Any support or utils used by more than on feature
    + io
    + config
    + persistence
    + web

Nie lubię nazw 'impl' lub 'support', ale pomagają one oddzielić mniej ważne rzeczy od ważnych (domeny i API). Jeśli chodzi o nazewnictwo, lubię być jak najbardziej konkretny. Jeśli masz pakiet o nazwie 'utils' z 20 klasami, przenieś {[1] } do support / string, HttpUtil do support / http i tak dalej.

Czy istnieją najlepsze praktyki dotyczące organizacji pakietów w Javie i co w nich jest?

(proszę przeczytać No best Practices , aby zapoznać się z "najlepszymi praktykami" i ludźmi, którzy je promują.)

(Cykliczne zależności między klasami w pakiecie / module są w porządku, ale cykle między pakietami utrudniają zrozumienie architektury aplikacji i mogą być przeszkodą w ponownym użyciu kodu. W szczególności, jeśli używasz Mavena, przekonasz się, że cykliczne zależności między pakietami / między modułami oznaczają, że cały połączony bałagan to musi być jeden artefakt Mavena.)

Powinienem również dodać, że istnieje jest jedna powszechnie akceptowana najlepsza praktyka dla nazw pakietów. Oznacza to, że nazwy pakietów powinny zaczynać się od nazwy domeny organizacji w odwrotnej kolejności. Jeśli zastosujesz się do tej zasady, zmniejszysz prawdopodobieństwo problemów spowodowanych przez zderzanie się nazw Twoich (pełnych) klas z nazwami innych ludzi.

Widziałem, jak niektórzy promują "pakiet po warstwie" nad "pakiet po warstwie", ale przez wiele lat korzystałem z kilku podejść i uznałem "pakiet po warstwie" znacznie lepiej niż "pakiet po warstwie".

Poza tym odkryłem, że strategia hybrydowa: 'pakiet po module, warstwa potem funkcja' działa bardzo dobrze w praktyce, ponieważ ma wiele zalet 'pakiet po funkcji':

• promuje tworzenie frameworków wielokrotnego użytku (bibliotek z obu modeli i UI aspekty)
• pozwala na implementacje warstw typu plug and play - praktycznie niemożliwe w przypadku 'package by feature', ponieważ umieszcza implementacje warstw w tym samym katalogu/pakiecie co kod modelu.
Wiele więcej...

Wyjaśnię tu szczegółowo: struktura i Organizacja nazw pakietów Java ale moja standardowa struktura pakietów jest:

Revdomain.typ modułu.nazwa modułu.warstwa.[layerImpl].cecha.subfeatureN.subfeatureN+1...

Gdzie:

revdomain Reverse domain np. com.mycompany

moduleType [app* / Framework / util]

moduleName np. myAppName jeśli Typ modułu jest aplikacją lub 'finance' jeśli jest to struktura księgowa

layer [model / ui|trwałość / bezpieczeństwo itp.,]

layerImpl np., wicket, jsp, jpa, jdo, hibernate (Uwaga: nie jest używany, jeśli warstwa jest modelem)

feature np., Finanse

subfeatureN np., księgowość

subfeatureN+1 np., amortyzacja

*czasami 'app' jest pomijane, jeśli ModuleType jest aplikacją, ale umieszczenie go tam sprawia, że struktura pakietu jest spójna we wszystkich typach modułów.

Nie znam standardowych praktyk organizacji pakietów. Zazwyczaj tworzę pakiety, które obejmują dość szerokie spektrum, ale mogę rozróżnić w ramach projektu. Na przykład, osobisty projekt, nad którym obecnie pracuję, zawiera pakiet poświęcony moim dostosowanym kontrolkom interfejsu użytkownika (pełnym klas podklasujących klasy swing). Mam pakiet poświęcony moim problemom z zarządzaniem bazami danych, mam pakiet dla zestawu słuchaczy / wydarzeń, które stworzyłem, i tak dalej.

On the other ręka kazałem współpracownikowi stworzyć nowy pakiet dla prawie wszystkiego, co zrobił. Każdy inny MVC, którego chciał, miał swój własny pakiet i wydawało się, że zestaw MVC jest jedyną grupą klas, która może być w tym samym pakiecie. Pamiętam, że w pewnym momencie miał 5 różnych pakietów, z których każdy miał jedną klasę. Myślę, że jego metoda jest trochę ekstremalna (a zespół zmusił go do zmniejszenia liczby pakietów, gdy po prostu nie mogliśmy sobie z tym poradzić), ale dla nietrywialnej aplikacji, więc umieszczanie wszystko w jednym opakowaniu. To punkt równowagi, który ty i twoi koledzy z drużyny musicie znaleźć dla siebie.

Jedną z rzeczy, które możesz zrobić, to spróbować się cofnąć i pomyśleć: gdybyś był nowym członkiem wprowadzonym do projektu, lub twój projekt został wydany jako open source lub API, jak łatwo/trudno byłoby znaleźć to, czego chcesz? Bo dla mnie to jest to, czego naprawdę chcę od pakietów: organizacja. Podobnie jak w przypadku przechowywania plików w folderze na komputerze, spodziewam się, że będę mógł je ponownie znaleźć bez konieczności przeszukiwania całego dysku. Oczekuję, że będę w stanie znaleźć klasę, którą chcę, bez konieczności przeszukiwania listy wszystkich klas w pakiecie.