wykład na JUG 13marca

[l.kuczera]

Witam,
Mam propozycję zrobienia prezentacji nt. wzorców projektowych, głównie
praktycznego zastosowania na przykładach. Napiszcie co sądzicie o tym.

pozdrawiam

[Jakub Neumann]

> Mam propozycję zrobienia prezentacji nt. wzorców projektowych, głównie
> praktycznego zastosowania na przykładach. Napiszcie co sądzicie o tym.

Wzorce (i antywzorce) projektowe zawsze na czasie. Gdyby tak jeszcze coś
z aplikacji JEE to byłaby bomba. Dla mnie temat super.

Kuba

[cypr...@gmail.com]

Swego czasu interesowałem się wzorcami, zarówno ogólnie, jak i w j2ee,
ale jedynie sam i książkowo, bo nie było z kim przedyskutować podczas
tworzenia aplikacji. Jestem jak najbardziej za! A już tymbardziej w
jee. Ogólnie używam tylko podstawowych i z chęcią bym się dowiedział,
z czego się najczęściej korzysta w praktyce.

[Kuba.Ma...@gmail.com]

Wydaje mi się że większą wagę możnaby położyć na wzorce strukturalne.
Tych się używa regularnie.
Wzorce j2ee - choć niewątpliwie są ciekawe i warto je znać -
pozwalają lepiej zrozumieć działanie i funkcjonowanie już napisanych
frameworków. Bo powiedzcie szczerze, kto w codziennej pracy staje
przed problemem napisania własnego app controllera ;-)


Kuba

[Jakub Neumann]

Kuba.Ma...@gmail.com pisze:

No właśnie, wzorce j2ee, ciekaw jestem jakie macie z nimi doświadczenia
w codziennej pracy. Może coś z tych:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

Kuba

[cypr...@gmail.com]

Ja piszę coś takiego ;) App controller (mapowany na *.html), który
wyciąga z bazy nazwę kontrolera do obsługi wybranego adresu url i
dalej używa Command, przy okazji dołącza FacesContext, jeśli jest
potrzebne, generuje menu itp. Dobrze wiedzieć, czy takie podejście
jest dobre, czy można by lepiej podłączyć się do wbudowanych
mechanizmów, dynamicznie podpiąć się pod mapowanie url, a dodatkowe
akcje wykonywać w filtrach np.

[Jacek Laskowski]

2008/3/5 <Kuba.Ma...@gmail.com>:

> Bo powiedzcie szczerze, kto w codziennej pracy staje
> przed problemem napisania własnego app controllera ;-)

To mogłoby być ciekawym tematem na spotkanie: czy pozostajemy przy tym
co mamy, czy tworzymy coś nowego, co ostatecznie może być bardziej
rewolucyjne? Czym więcej człowiek poznaje, tym coraz bardziej
intryguje go pytanie, co sprawia, że ludzie tworzą coś nowego. Czy
może nadeszła pora zabrać się właśnie za coś nowego?

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

[Kasia eŚ]

Mam pytanie, czy z tego wykładu, będą dostępne później jakieś
materiały na grupie? Nie mogę dziś niestety przyjść, a nie chciałabym,
że by mnie zupełnie temat ominął.

[Bartłomiej Opajdowski]

Na która godzine wyklad??

[l.kuczera]

Materiały dostępne na grupie a także tutaj.
Lektura którą polecam to:

Design Patterns: Elements of Reusable Object-Oriented Software.
Gamma, Helm, Johnson, Vlissides, 1995

Holub on Patterns, Allen Houlub - Game of Life jest jego autorstwa

http://www.holub.com/goodies/patterns/index.html

Gorąco polecam JUnit cook tour

http://junit.sourceforge.net/doc/cookstour/cookstour.htm

A także książki wymienione na stronie Allena.

Jeżeli ktoś ma jakieś pytania odnośnie wykładu z chęcią odpowiem.
Tematyka wbrew pozorom nie jest ciężka.

[l.kuczera]

Tutaj :)
http://jextreme.pl/design_patterns/

[cypr...@gmail.com]

Nie spoglądałem jeszcze w kod GoL, ale z tego co zrozumiałem, to po
zmianie stanu kwadracika Observer dodaje go do listy dla Visitatora,
żeby go odwiedził, który jest odpalany co X milisekund, tak?

[Grzegorz D]

hmm, na prezentacji Łukasza widziałem jak miał podpięte Source javy
pod eclipse (oraz podpowiadał razem z dokumentacja). No i muszę
przyznać że spodobało mi się to..... Tylko szukam po stronach suna,
szukam i szukam ....... i chyba nie jest dane mi znaleźć tych
zipów ;]

[Cyprian]

src.zip jest zawarty w SDK SE, praktycznie wystarczy skopiować go do katalogu jdk i eclips go sam znajdzie. (ponieważ nie ma go w wersji JEE) plik się nazywa src.zip

16-03-08, Grzegorz D <Grzegorz...@gmail.com> napisał(a):

[Grzegorz D]

dzieki, działa tak jak powinno

On 16 Mar, 03:45, Cyprian <cypria...@gmail.com> wrote:
> src.zip jest zawarty w SDK SE, praktycznie wystarczy skopiować go do
> katalogu jdk i eclips go sam znajdzie. (ponieważ nie ma go w wersji JEE)
> plik się nazywa src.zip
>

> 16-03-08, Grzegorz D <Grzegorz.Deme...@gmail.com> napisał(a):

>
>
>
> > hmm, na prezentacji Łukasza widziałem jak miał podpięte Source javy
> > pod eclipse (oraz podpowiadał razem z dokumentacja). No i muszę
> > przyznać że spodobało mi się to..... Tylko szukam po stronach suna,
> > szukam i szukam ....... i chyba nie jest dane mi znaleźć tych
> > zipów ;]
>

> --
> pozdrawiam
> Cyprian Śniegota

[l.kuczera]

Ten fragment jest dość ciekawy. Proponuję otworzyć kod źródłowy bo bez
niego ciężko będzie śledzić to o czym napiszę. Stan kwadracików w tym
miejscu nas nie interesuje.

Klasa Clock jest konkretnym podmiotem i rozsyła do obiektów
obserwujących(wie o nich jedynie że implementują interface Listener),
powiadomienia o tyknięciach zegara. Tyknięcia występują w równych
odstępach czasu (ustawiane w menu). Wizytator został użyty w celu
ominięcia problemu ze Swing'iem. Swing rozsyła w osobnym wątku
powiadomnienia, proste zastosowanie obserwatora niestety nie jest
możliwe. Mogą występować konfilikty wątku głównego programu z wątkiem
rozsyłania zdarzeń Swing. Można to ominąć na kilka sposobów. Jeden to
synchronizacja, na przeszkodzie stoi brak informacji jak długo będzie
wykonywał się kod obserwatora a co za tym idzie nie mamy dostępu do
listy subskrybentów w tym czasie. Inny sposób polega na kopiowaniu
listy obserwatorów przed wysyłaniem powiadomnień, jednak może być
kosztowny.

W Game of Life rozwiązanie wykorzystuje wizytatora i niemutowalne
obiekty. Interface Publisher.Distributor jest wizytatorem, a metoda
deliverTo(Object subscriber) jest metodą visit() z GoF. (zauważmy że
jest tylko jedna metoda visit).
W Publisher jest jeszcze jedna klasa: Node. Jest to lista
subskrybentów jak również struktura danych dla wizytatora (metoda
accept(Distributor deliveryAgent);). Klasa ta jest niezmienna czyli
nie ma potrzeby żeby dostęp do niej był synchronizowany. Publisher (a
nie Clock) utrzymuje listę subskrybentów, ale nie wie nic o
zdarzeniach dlatego to Clock uczestniczy w obserwatorze a nie
Publisher. Jedyne zadanie tej klasy to dostarczyć powiadomienie
poprzez Distributor'a Publisher.publish(Publisher.Distributor
distributor); W tym kontekscie distributor jest obiektem polecenia
gdyż publisher nie wie nic o działaniu distributora a jedynie wywołuje
jego metodę deliverTo(Object subscriber). Rola Publishera sprowadza
się zatem do zarządzania listą subskrybentów. Obiekty Node definiują
metodę accept(Publisher.Distributor deliveryAgent) { // wizytator
deliveryAgent.deliverTo(subscriber); // subscriber jest prywatnym
polem Node
}

Jakie są korzyści tego rozwiązania ? Sami definiujemy w jaki sposób
powiadomienia o zdarzeniach mają być dostarczane poprzez implementacje
Publisher.Distributor (jest to też wzorzec command) Publisher dzięki
temu może być wykorzystywany w praktycznie dowolnym środowisku bez
konieczności zmian. Interfejs Publisher nie jest w żaden sposób
powiązany z obserwatorem czyli możemy wykorzystać go w dowolnym
kontekście (nie jesteśmy ograniczeni do używania jakiegoś konkretnego
interfejsu obserwatora). Publisher grzecznie przyjmuje od nas obiekt
wizytatora (Publisher.Distributor) następnie iteruje po Liście
subskrybentów i na każdym wywołuje metodę accept(distributor).

Przygotuję diagram sekwencj jak ten kod działa. Na pierwszy rzut oka
wygląda na skomplikowany, ale bardzo elegancko rozwiązuje problem
dostarczania powiadomień :)

pozdrawiam.