Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Witajcie,

Mam problem z ustaleniem nazw dla poszczególnych plików/klas w projekcie w ramach danego pakietu. Niektóre klasy mają takie same nazwy w ramach różnych pakietów i tutaj tworzy się problem w sytuacji, gdy muszę w ramach np. jednego servleta użyć tych klas.

Przedstawię problem na przykładzie klasy Panel.
- Panel.java w pakiecie entities
Tutaj umieszczam jak sama nazwa wskazuje klasy odwzorowujące tabele z bazy danych na obiekt. Tym samym tabela 'panel' ma swój odpowiednik w klasie Panel.java która zawiera tylko i wyłącznie definicję poszczególnych pól z tabeli w db (setXXX(), getXXX())

- Panel.java w pakiecie libs
W tym miejscu sa klasy zawierające róznego rodzajy mechanizmy/algorytmy w ramach danego elementu aplikacji

- Panel.java w pakiecie models
Tutaj są wykonywane operacja na bazie danych w ramach danego elementu aplikacji

Skrócona struktura aplikacji
entities
- Panel.java

servlets
- servlety

models
- Panel.java

libs
- Panel.java
- Action.java
libs.panel
- Param.java
libs.action
- Param.java


Teraz korzystanie z tego typu struktura jest trochę problematyczne. Gdyż w ramach np. danego servleta gdy potrzebuję użyć klas Panel.java z róznych pakietów to tworzy się konflikt.
Poprzedzanie klas nazwą pakietu jest mało estetyczne moim zdaniem. czy mogę to rozwiązać jakoś inaczej ?

Myślę by po nazwie klasy dopisywać suffix pakietu w l. pojedyńczej np.
- PanelEntity.java
- PanelModel.java
- PanelLib.java

Ale tutaj przeczy to idei stosowania pakietów. Jak Waszym zdaniem powinienem rozwiązać ten problem i zorganizować strukturę aplikcji??

Podobnie jest problem ze strukturą drzewiastą pakietów.
W pakiecie libs mam podpakiety, a w nich są pliki o nazwach które już wystapiły w innych podpakietach w ramach tego pakietu libs np.
- Param.java w pakiecie libs.panel oraz libs.action

Tutaj też nie usmiecha mi się stosowac nazwy w stylu:
- PanelParam.java
- ActionParam.java

Za bardzo niewiem jak to ugryźć :/

Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Staraj się nie powtarzać nazw klas choćby z tak błahego powodu, jak ten, że szlag Cię trafi przy CTRL+SHIFT+T w Eclipse :)

Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Powtarzanie nazw klas to "big No No", tego powinno się zawsze unikać. Takie same nazwy:
- zaciemniają która klasa co robi
- utrudniają nawigację skrótami w IDE

Jak dla mnie od razu widać, że masz zbyt ogólne nazwy klas i to powoduje problemy. Ten Panel jest przeznaczony pod konkretną encję albo zastosowanie, więc niech to ma odzwierciedlenie w nazwie i będzie dużo prościej.

A odnośnie pakietów to dzięki nim możesz:
- ograniczać wiedzę innych klas z innych pakietów o metodach z danego pakietu
- grupować razem klasy, które odpowiadają za jakiś moduł/funkcjonalność

Więc generalnie polecam ich stosowanie :)

Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Hmm może faktycznie nazwy mało mówią o tym jaka jest ich odpowiedzialność.
Jeśli chodzi o klasę 'Panel' dla encji, to tutaj raczej nazwa jest ok.

W kwestii klas związanych z operowaniem na bazie danych w ramach danej encji, mam kilka pomysłow:
- dopisywać do klasy Managed (np. PanelManaged.java) - w tym momencie może to segurować że jest to klasa zarządcza encją Panel.
- bardziej popularna metoda stosowana przez wiele osób, to dopisanie skrótu Dao (Data Access Object) na końcu klasy (np. PanelDao.java)

zastanawiam się jak zorganizować strukturę drzewiastą klas:

Jeśli użyję do tego celu tylko pakiety to nazwy zaczną mi się powtarzać np:
/xxx.daos
- - PanelDao.java
- - ActionDao.java
- - /xxx.daos.panel
- - - - ParamDao.java (fail)
- - /xxx.daos.action
- - - - ParamDao.java (fail)

Wnioski są takie że pakiety najlepiej nie stosować w takiej postaci jak wyżej, naklepiej zrobić to tak:
/xxx.daos
- - PanelDao.java
- - ActionDao.java
- - PanelParamDao.java
- - ActionParamDao.java

Co o tym sądzicie, czy taka organizacja plików jest poprawna i do przyjęcia w świecie Javy ? :) W projektach pisanych w PHP stosowało się właśnie to ostatnie rozwiązanie powyżej i to było normą.

Co do samego pakietu libs. Tutaj zapewne będę tworzył bardziej szczegółowe struktury klas o ściśle zdefiniowanych funkcjach. Zobaczymy co z tego wyjdzie ;)Sławomir J. edytował(a) ten post dnia 18.07.12 o godzinie 12:10

Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Sławomir J.:
Co o tym sądzicie, czy taka organizacja plików jest poprawna i do przyjęcia w świecie Javy ? :) W projektach pisanych w PHP stosowało się właśnie to ostatnie rozwiązanie powyżej i to było normą.

Z mojego punktu widzenia wszystko jedno, czy to Java, PHP, Haskell, Prolog czy Scala ;)

Organizacja plikow powinna wynikac z architektury Twojego programu (moduly, komponenty, jednostki kompilacji itp.). Jesli nie masz konkretnej zdefiniowanej architektury, przemysl to ;)

Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Wnioski są takie że pakiety najlepiej nie stosować w takiej postaci jak wyżej, naklepiej zrobić to tak:
/xxx.daos
- - PanelDao.java
- - ActionDao.java
- - PanelParamDao.java
- - ActionParamDao.java

Nie wiedząc o co dokładnie chodzi, na pierwszy rzu oka bym zrobił tak:

pl.aplikacja.dao.action:
-- ActionDao.java
-- ActionParamDao.java

pl.aplikacja.dao.panel:
-- PanelDao.java
-- PanelParamDao.java

Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Pawel Dolega:

>

Nie wiedząc o co dokładnie chodzi, na pierwszy rzu oka bym zrobił tak:

pl.aplikacja.dao.action:
-- ActionDao.java
-- ActionParamDao.java

pl.aplikacja.dao.panel:
-- PanelDao.java
-- PanelParamDao.java

A na drugi rzut oka, również nie wiedząc o co chodzi, być może PanelParamDao i ActionParamDao będą robić de facto to samo, tyle że na rzecz klas Panel i Action, i być może będzie można wtedy wszystko wyrzucić do nadrzędnej klasy ParamDao<T>

Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Ciekawy temat, to się podepnę:
jak grupować klasy ?
a) tematycznie ze względu na strukturę wrzucone do tego samego pakietu (encje ORM w jednym pakiecie, klasy DAO w drugim, controlery w trzecim itd)
b) tematycznie ze względu na funkcje w systemie do tego samego pakietu (Product, ProductDAO, productService, ProductController w jednym pakiecie, Panel, PanelDAO, PanelService, PanelController w kolejnym, itd)

osobiście stosowałem rozwiązanie a), ze względu na to, iż Spring (bo w nim rzeźbię większość projektów) wyszukiwał automatycznie odpowiednie komponenty, za pomocą odpowiednich wyrażeń regularnych ustawionych w konfiguracji xml-owej. Dzięki temu klasy ładowały się szybciej, a w bardzo prostych przypadkach wystarczy podać klasę jednego pakietu, gdzie są np. wszystkie kontrolery i sprawa załatwiona.
Jakie są plusy rozwiązania b) ? widzę w niektórych projektach takie rozwiązania, nie wiem co skłania do układania klas w ten sposób. Chyba tylko możliwość innego ustawienia widoczności zmiennych daje pewną przewagę.

pzdrAndrzej Cichoń edytował(a) ten post dnia 18.07.12 o godzinie 15:29

Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Andrzej Cichoń:
Ciekawy temat, to się podepnę:
jak grupować klasy ?

I tak i tak ;)
Jedno to modularyzacja pozioma (czyli warstwy aplikacji), drugie - pionowa (czyli podzial ze wzgledu na funkcje biznesowa). W zasadzie dobrze by bylo, zeby w aplikacji istnialy oba wymiary, ktory bedzie dominujacy, to juz kwestia indywidulnego projektu.

Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Miłosław F.:

Andrzej Cichoń:
Ciekawy temat, to się podepnę:
jak grupować klasy ?

I tak i tak ;)
Jedno to modularyzacja pozioma (czyli warstwy aplikacji), drugie - pionowa (czyli podzial ze wzgledu na funkcje biznesowa). W zasadzie dobrze by bylo, zeby w aplikacji istnialy oba wymiary, ktory bedzie dominujacy, to juz kwestia indywidulnego projektu.

Takie podejście stosuję w przypadku projektów w których tworzę portlety lub task flowy ADF. Wtedy mam np. pakiety

com.cośtam.portlet.A
com.cośtam.portlet.A.dao
com.cośtam.portlet.A.service
com.cośtam.portlet.A.web
com.cośtam.portlet.B
com.cośtam.portlet.B.dao
com.cośtam.portlet.B.service
com.cośtam.portlet.B.web

A co tylko da się wyciągnąć do nadklas w

com.cośtam.portlet.common.dao
com.cośtam.portlet.common.service

itp.

W przypadku zwykłej aplikacji webowej:

com.cośtam.app.dao
com.cośtam.app.service

A w nich podpakiety (tak samo nazwane) grupujące DAO/serwisy/model dla poszczególnych funkcjonalności biznesowych.

Pewien problem zawsze mam z klasami wyjątków - zwykle pcham je do tego samego pakietu co serwisy (jako że najczęściej ta warstwa sypie wyjątkami), jednak czasem pasują mi gdzieś "wyżej" i wtedy tam lądują.

Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Odnośnie nadawania struktury pionowej vs poziomej:
Najpierw pionowa (nazwijmy to na potrzeby naszej dyskusji moduły systemu), a w obrębie modułu pozioma - czyli warstwy.

Z bardzo prostej przyczyny: różne moduły możesz projektować wg różnych architektur *aplikacji* (różnych warstw, lub architektur *aplikacji* innych niż warstwowe) w zależności od poziomu ich komplikacji. Np dla problemu klasy CRUD wystarczy 1 warstwa i 5 praktykantów, dla Core Domain (pojęcie z DDD) możesz potrzebować nawet 7 warstw:)

Zapraszam do zapoznania się z projektem ilustrującym strukturę nieco większego systemu: http://code.google.com/p/ddd-cqrs-sample/ (licencja Apache 2.0) - ok 50 stron a4 w wiki;
a tak to wygląda http://prezi.com/hi2dmhfej9zu/ddd-cqrs-sample/ - scroll pozwala na zoom, linki są kilkalne i prowadzą do SVN.

Co do struktury to można zadać pytanie: dlaczego Encje i Model zostały rozszczepione?
Aby uprościć można przyjąć, że cechą modelu jest to, że jest persystentny...

Co do nazewnictwa, to można uruchomić słowiańską fantazję popartą zasadami SOLID, GRASP, RDD i np w libach tworzyć klasy PanelMatcher, PanelCalculator, PanelTransformer itd... Intuicja mówi mi, że Panel w libach to paczka procedur udająca Object Oriented:PSławomir Sobótka edytował(a) ten post dnia 18.07.12 o godzinie 23:19

Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Może wyjaśni w skrócie, same założenia mojej aplikacji. Ułatwi to zrozumienie koncepcji i na pewno ubarwi tę dyskusję :)

W ramach pracy magisterskiej, postanowiłem opracować narzędzie do tworzenia interfejsów użytkownika wraz całą logiką biznesową. Innym słowem chcę umożliwić tworzenie ekranów (stron www) zawierających wybrane komponenty (panele). Każdy panel zawiera charakterystyczne dla siebie elementy/parametry. Wszystko ma być możliwe do wykonania przy pomocy samej przeglądarki, bez pisania kodu (czyli po prostu możemy wyklikać całą aplikację).
Aby ułatwić sprawę. przykładowymi panelami mogą być: formularze, listy oraz zwykłe warstwa z treścią które będą umieszczane na ekranach.

Poniżej zamieszczam zmodyfikowaną strukturą swojej aplikacji, która powstała po przestudiowaniu Waszych porad :) (oczywiście lista jest mocno okrojona). Udało się tutaj zlikwidować powtarzanie nazw dla plików, co było moim głównym celem :)

/agis.servlet
--- AbstractServlet.java (jest to główny servlet po którym dziedziczą wszystkie inne servlety, tutaj są wywoływane odpowiednie metody docelowych servletów)

--- /agis.servlet.panel
------ PanelListServlet.java (Lista paneli w ramach danego ekranu)
------ PanelCreateServlet.java (Formularz do tworzenia nowego panelu w ramach danego ekranu)
------ PanelDefinitionServlet.java (Formularz do edycji danego rekordu panelu)

--- /agis.servlet.screen
------ ScreenListServlet.java (Lista ekranów)
------ ScreenCreateServlet.java (Formularz do tworzenia nowego ekranu)
------ ScreenDefinitionServlet.java (Formularz do edycji danego rekordu ekranu)

/agis.entity
-- Screen.java (Encja dla tabeli 'screen')
-- Panel.java (Encja dla tabeli 'panel')

/agis.dao (mechanizmy wykonujące określone czynności na danych w bazie danych)
--- /agis.dao.screen
------ ScreenDao.java (metody dostępu do danych ekranów - dodawanie/edycja/usuwanie/pobieranie)
--- /agis.dao.panel
------ PanelDao.java (metody dostępu do danych paneli - dodawanie/edycja/usuwanie/pobieranie)
------ PanelParamDao.java (metody dostępu do danych parametrów dla danego panelu - dodawanie/edycja/usuwanie/pobieranie)

/agis.lib (narzędzia zawierające różnego rodzaju algorytmy)
--- /agis.lib.action (akcje jakie mogą być wykonane w ramach wywołania servletu)
------ Action.java (klasa abstrakcyjna)
------ ActionForward.java (akcja typu forward())
------ ActionPlainText.java (akcja która wyrzuca na ekran czysty tekst - np. do wywołan ajaxowych)
------ ActionRedirect.java (akcja typu redirect(), wykonująca przekierowanie żadania)
--- /agis.lib.panel
------ PanelBuilder.java
------ PanelManaged.java (mechanizmy do tworzenia paneli, musi być przykryty przez klasę już konkretnego panelu - poniżej)
------ PanelFormManaged.java (mechanizmy do tworzenia panelu typu formularz)
------ PanelGridManaged.java (mechanizmy do tworzenia panelu typu grid/lista)
------ PanelContentManaged.java (mechanizmy do tworzenia panelu typu tresc)

/agis.tag (własne tagi dla widoków)
--- TemplateTag.java (tag pozwala załadować inny widok zdefiniowany jako szablon aplikacji)

/agis.tool (tutaj będą znajdować się proste przydatne narzędzia zawierające metody z kodem które często się powtarzają)
--- Type.java (np. statyczna metoda do Konwersja typu String na int)

/agis.enums
--- RequestMethods.java (typy żadan: POST, GET)

Temat: Struktura aplikacji - ustalenie nazwy powtarzających...

Sławomir Sobótka:
Odnośnie nadawania struktury pionowej vs poziomej:
Najpierw pionowa (nazwijmy to na potrzeby naszej dyskusji moduły systemu), a w obrębie modułu pozioma - czyli warstwy.

Tak, prawda. Wlasciwie to nie przychodzi mi spontanicznie do glowy zaden przyklad, zeby warto bylo robic odwrotnie ;)