Wzorce projektowe - czy warto?

0

Mam pytanie dot. tworzenia wzorców UML dla swoich projektów.
Znam w miarę dobrze C++, teraz od miesiąca uczę się Javy.
Napisałem już parę użytecznych programów, jednak nie były one raczej skomplikowane pod względem hierarchii klas.
Teraz chciałbym wziąć się za coś poważniejszego, chociażby grę 2D w javie.
Mam jednak problem z zaprojektowaniem hierarchii klas, relacji między obiektami itd.

Oczywiście nie mam problemów z prostymi relacjami typu Firma - Pracownik, jednak w grze (nawet prostej) pojawiają się klasy takie jak np. Gra, WątekGry, Symulacja, ObsługaWejścia, Świat, StanGry itd.
Nie jest łatwo poukładać to wszystko tak, żeby wszystkie obiekty miały dostęp do potrzebnych danych (chyba, że użyjemy zmiennych globalnych, albo wiele obiektów będzie wyposażonych w uchwyty do innych obiektów, co jest raczej nieeleganckie).

Czy wg. was jest to odpowiedni moment, żeby nauczyć się tworzenia diagramów UML?
Jeżeli tak, to jakie typy diagramów powinienem opanować?

Z góry dziękuję!

0

Widzę że nikt nie odpowiedział w wątku więc zrobię to ja - chociaż autorytetem na temat IO (jeszcze ;) ) nie jestem.

Chcesz projektować dobre programy? To dobrze (znaczy że się rozwijasz i w przyszłości może nawet nie będziesz zwykłym klepaczem :) ). Tylko nie pójdź w tą stronę co ja kiedyś - przez pewien czas miałem fazę na wzorce projektowe, inżynierie oprogramowania, etc etc.
Kiedy planowałem napisać jakąś trochę większą aplikację zamiast IDE otwierałem edytor UML i rysowałem grafy. Po czym wszystko wywalałem bo hierarchia mi się nie podobała.
Potrafiłem na raz wyrzucić połowę klas z działającego programu bo stwierdziłem że czas na 'refaktoryzację'.
Nie napisałem wtedy ani jednego działającego programu dłuższego niż 100 linijek :). Na szczęście po kilku miesiącach mi przeszło. Z drugiej strony dzięki temu mam (IMVHO) teraz w miarę wyważony stosunek i pisanie dobrych programów idzie mi coraz lepiej.

Diagram UML to tylko ładne przedstawienie tego co równie dobrze (a nawet lepiej) można naszkicować ołówkiem na okładce od zeszytu. Przydaje się wtedy kiedy na przykład pracujesz w grupie 10 osobowej i trzeba omówić hierarchię klas. Wtedy wszyscy którzy znają UML wiedzą o co chodzi i dyskusja przebiega prościej.
UML twojego programu nie zaprojektuje.
No i przede wszystkim - UML za ciebie projektu nie napisze. Możesz się zakopać w diagramach tylko że nie ruszysz przez to do przodu...

Jeśli chcesz pisać kod dobrej jakości (a to dobrze że chcesz) to kup jakąś dobrą książkę na ten temat, przeczytaj, spróbuj zastosować w praktyce. Pewnie na początku nie wszystko będzie Ci wychodzić ale to kwestia czasu.
UML bym zostawił na potem, ale jeśli bardzo chcesz możesz o nim poczytać bo opanowanie ich na poziomie rozumiem o co chodzi to kilka godzin. Najważniejsze diagramy to diagram klas i diagram use-case, przydaje się jeszcze czasami np. jeśli chcesz spojrzeć z szerszej perspektywy na swój kod diagram maszyny stanowej (przy maszynach stanowych FSM) i czasami diagram przepływu (wyobrażam sobie zastosowanie w jakichś punktach krytycznych). Więcej w zwykłych okolicznościach się nie przyda...

0

Temat jest o wzorcach projektowych, a pytania dotyczą UML. Nie rozumiem zupełnie, co autor miał na myśli.

MSM napisał(a)

No i przede wszystkim - UML za ciebie projektu nie napisze.

Można wygenerować kod z diagramów UML.
Diagramy mają tę zaletę, że stanowią od razu dokumentację projektową. Z tymże, ponieważ zmiany w strukturze projektu są w zasadzie nieuniknione (no chyba, że ktoś jest taki świetny, że od razu potrafi zaprojektować doskonałą strukturę), to diagramy trzeba uaktualniać, a z tym jest już problem (czas, chęci).
Nauczyć się UML można, bo a nuż przyda się w pracy zawodowej, w zespole. W projektach jednoosobowych mają raczej mniejszy sens, ja sobie wolę projekt narysować "po swojemu" na kartce.

Najważniejsze diagramy to diagram klas i diagram use-case, przydaje się jeszcze czasami np. jeśli chcesz spojrzeć z szerszej perspektywy na swój kod diagram maszyny stanowej (przy maszynach stanowych FSM) i czasami diagram przepływu (wyobrażam sobie zastosowanie w jakichś punktach krytycznych).

W UML nie ma diagramu przepływu. Jest za to diagram sekwencji, przydatny wtedy, gdy chcemy zaprezentować kolejność realizacji jakiejś akcji z uwzględnieniem komunikacji między warstwami aplikacji (np. od kliknięcia przez użytkownika przycisku na stronie, przez różne klasy aplikacji, aż do zapisu rekordu w bazie danych). Moim zdaniem jest w pierwszej trójce najważniejszych diagramów. Przydatny jest też diagram czynności, bo pozwala opisać algorytmy.

Smigiel napisał(a)

Mam jednak problem z zaprojektowaniem hierarchii klas, relacji między obiektami itd.

Oczywiście nie mam problemów z prostymi relacjami typu Firma - Pracownik, jednak w grze (nawet prostej) pojawiają się klasy takie jak np. Gra, WątekGry, Symulacja, ObsługaWejścia, Świat, StanGry itd.
Nie jest łatwo poukładać to wszystko tak, żeby wszystkie obiekty miały dostęp do potrzebnych danych (chyba, że użyjemy zmiennych globalnych, albo wiele obiektów będzie wyposażonych w uchwyty do innych obiektów, co jest raczej nieeleganckie).

UML w tym ani trochę nie pomoże. UML to tylko standard rysowania i opisywania projektów. Ty potrzebujesz wiedzy z analizy i projektowania obiektowego oraz wzorców projektowych.

0

Zgadzam się, sam UML tego nie nauczy - nabędziesz tylko (ale przydatną) możliwość wizualizacji struktury i działania swoich projektów. Odpowiedź na pytanie, czy się uczyć UML: tak.
Wzorce projektowe - podstawa tworzenia aplikacji komercyjnych. To po prostu pomaga w pracy.
Natomiast w pytaniach jaki zakres odpowiedzialności przydzielić klasie, jakie powiązania miedzy nimi, która klasa jakie obiekty ma tworzyć mogą Ci pomóc wzorce GRASP (twórca, kontroler, ekspert etc.)

1 użytkowników online, w tym zalogowanych: 0, gości: 1