Autor Wątek: Java - pakiety  (Przeczytany 3466 razy)

Offline LizarD

  • Użytkownik

# Marzec 14, 2013, 11:52:18
Witam!

Podobno jeżeli nie rozumiem sensu pakietów to nie rozumiem całej jawy. Pakiety pozwalają na przechowywanie np klas, w każdym pakiecie mogą byc różne klasy. Pakiety można udostępniać innym pakietom tylko pytanie po co ? Jaka jest tego zaleta ? W czym to pomaga ?
Swoja drogą pisząc coś na Androida przy tworzeniu projektu podaję nazwę pakietu musi ona wyglądac mniej więcej tak com.costam.costam, dlaczego są to 3wyrazy odzielone kropką ? Co jeżeli stworzę projekt bez aktywności ( tworząc z IDE automatycznie dodaje klasę do tego pakietu ) i nie dodam swojej klasy ( ręcznie utworzonej aktywności ) do tego pakietu ? Wyląduje on w czymś takim "(default package)" tylko jaki będzie tego skutek ?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline akzyl

  • Użytkownik

# Marzec 14, 2013, 12:56:55
Najlepiej to poczytać sobie o roli pakietów w javie (naprawdę jest masa artykułów w necie).

Od siebie dodam tyle mam projekt napisany w SWING'u sam projekt składa się obecnie z około 120 modułów (biblioteki jar) w każdym z modułów jest po kilka, kilkanaście a nawet i kilkadziesiąt klas.
Z twoim podejściem miałbym pakiet defaultowy a w nim dziesiątki tysięcy klas.
A teraz zadaj sobie pytanie musisz zrobić zmianę w jednej z klas weź mi ją znajdź nie szukając jej po referencjach z innych klas.
Jeżeli używasz sensownych nazw pakietów i wiesz, za co dany pakiet odpowiada to znalezienie danej klasy nie stanowi większego problemu.
Oczywiście to jest tylko jedna z korzyści, bo dochodzą jeszcze uprawnienia, ale o tym już nie chce mi się rozpisywać.

Suma sumarum wyobraź sobie bibliotekę, w której wszystkie książki są ułożone na jednej wielkiej kupce tym właśnie może skutkować brak pakietów.

« Ostatnia zmiana: Marzec 14, 2013, 13:28:10 wysłana przez akzyl »

Offline Xion

  • Moderator
    • xion.log

  • +1
# Marzec 14, 2013, 13:27:27
Pakiety to sposób na organizację kodu, co jest ważne zwłaszcza w większych projekatach. Poza tym częściowo rozwiązuje to też problem zduplikowanych nazw (chociaż akurat Java nie ma odpowiednio elastycznych dyrektyw importowania żeby sobie z tym radzić).

Wiele języków ma bardzo podobne mechanizmy: Python, Ruby, Go, Haskell, C#/.NET

Offline Kos

  • Użytkownik
    • kos.gd

# Marzec 14, 2013, 18:30:27
Wiele języków ma bardzo podobne mechanizmy: Python, Ruby, Go, Haskell, C#/.NET

Ma podobne, pytanie jak używa. To stosunkowo specyficzne dla Javy, by w nazwach pakietów czarować taksonomie typu org.eclipse.equinox.core.internal.mymodule.kwiatki.

Offline Xion

  • Moderator
    • xion.log

# Marzec 15, 2013, 01:47:36
Not really.

C#-owe namespace'y, poza standardowymi, też tak wyglądają (Microsoft.DirectX etc.).
W Haskellu wszystko jest w taksonomicznej hierarchii: wszystkie pakiety - także 3rd party - związane z przetwarzaniem tekstu lądują w Text, sieciowe w Network, itd.
Reszta wymienionych języków na górze stawia pojedyncze biblioteki, ale hierarchia zwykle jest używana - przy większych bibliotekach to zwykle 2, 3, czasem 4 poziomy.

Offline LizarD

  • Użytkownik

# Marzec 15, 2013, 12:39:08
Mniej więcej rozumiem ale nie mogę sobie wyobrazić praktycznego przykładu takiego zastosowania, chyba że na przykładzie jakiegos programu graficznego: klasy w jednym pakiecie odpowadają za GUI w drugim pakieie za rysowanie a w trzecim za np zmiane ustawień. Chyba o coś takiego chodzi ?

Czyli w aplikacjach androidowych nie ma większego sensu bawić się w pakiety tylko jak je nazywać tworzę projekt no i: com.xxxx.nazwa_projektu ? default ?
A co do projektowania pakietów, chyba nie dopuszczalne jest np taka sytuacja: jest pakiet A i pakiet B, te dwa pakiety nawzajem korzystaja ze swoich klas, pakiet A z klas pakietu B i pakiet B z klas pakietu A . W takiej sytuacji te dwa pakiety powinny być jednym pakietem. Zgadza się ?

Offline Xion

  • Moderator
    • xion.log

# Marzec 15, 2013, 12:47:15
Mniej więcej rozumiem ale nie mogę sobie wyobrazić praktycznego przykładu takiego zastosowania, chyba że na przykładzie jakiegos programu graficznego: klasy w jednym pakiecie odpowadają za GUI w drugim pakieie za rysowanie a w trzecim za np zmiane ustawień. Chyba o coś takiego chodzi ?
Chodzi o każdy podział programu/biblioteki na logiczne części. To np., co zaproponowałeś, ma sens. Podział na pakiety według długości nazw klas nie ma na przykład sensu.

Cytuj
Czyli w aplikacjach androidowych nie ma większego sensu bawić się w pakiety tylko jak je nazywać tworzę projekt no i: com.xxxx.nazwa_projektu ? default ?
Nazwa pakietu aplikacji z Google Play musi być (a ogólnie w Javie: powinna być) globalnie unikalna. Używa się więc odwróconych nazw domen, które posiadamy. Przykładowo, ja mam bloga/stronę na http://xion.io, więc pakiety mogę nazywać io.xion.<nazwa_projektu>.<podsystem>.etc.

Cytuj
A co do projektowania pakietów, chyba nie dopuszczalne jest np taka sytuacja: jest pakiet A i pakiet B, te dwa pakiety nawzajem korzystaja ze swoich klas, pakiet A z klas pakietu B i pakiet B z klas pakietu A . W takiej sytuacji te dwa pakiety powinny być jednym pakietem. Zgadza się ?
Kijem nikt cię za to nie zbije :) To, o co pytasz, to zagadnienia designu które raczej ciężko produktywnie omawiać bez konkretnych przykładów. Zamiast filozofować na takim "ogólnym" poziomie, mógłbyś się na przykład wziąć za ich implementację :)

Offline koirat

  • Użytkownik

  • +1
# Marzec 15, 2013, 15:44:40
A co do projektowania pakietów, chyba nie dopuszczalne jest np taka sytuacja: jest pakiet A i pakiet B, te dwa pakiety nawzajem korzystaja ze swoich klas, pakiet A z klas pakietu B i pakiet B z klas pakietu A . W takiej sytuacji te dwa pakiety powinny być jednym pakietem. Zgadza się ?

Jest jeszcze jedna opcja. Wydzielenie pakietu C który będzie zawierał część wspólną.