Projektuję mój pierwszy duży program w C++ w konsoli i mam odnośnie tego projektowania pytanie, żebym nie wyrobił sobie złych nawyków. W “Symfonii C++” autor napisał, że projektowanie składa się z 5 etapów. 4 nazywa się “Określenie wzajemnych zależności klas”. Chodzi o to, żeby napisać co która klasa oczekuje od drugiej i do czego ją zmusza.
Chodzi o taką tabelkę:
---------------- OBIEKT ---------------- ZALEŻNOŚĆ ---------------- KOGO ----------------
Menu:
Zleca narysowanie podglądu (wolnych i zajętych miejsc) [zmuszanie]
sali kinowej
Dowiaduje się od sali o możliwość wyświetlenia [dowiadywanie się]
podglądu
Nie wiem do czego jest to potrzebne. W poprzednich punktach powstały tzw. modele klas (właściwości, zachowania, przyjaciele klasy) i identyfikacja zachowań systemu (scenariusz - kto co robi, np. "Menu ---- rysuje ---- się ---- Rezultat: [wymieniam opcje, które pojawią się na ekranie]) i na podstawie tego pisze się relacje. No właśnie i w książce nawet w relacjach pojawia się obiekt jako MENU. To dobry pomysł ? Chodzi mi o to, że np. muszę pisać:
Menu — dowiaduje się czy dany film istnieje od — bazy danych
To samo powtarza się u mnie w innej klasie. Obiekt to już obiekt tej klasy. Dwa następne wiersze są już takie same. Nie wiem czy to ma sens pisanie takich powtarzających się rzeczy bo będzie ich pełno.
Może to jest bardzo szczegółowe ale jeszcze nigdy nie projektowałem tak dużego programu i być może ma to znaczenie już przy pisaniu kodu. A do niego został już tylko punkt 5 projektowania programu OO - polega on na tym, że pisze się po kolei (w punkcie pierwszym nie było to wymagane) co kto robi .
Mam wrażenie, że komplikujesz sobie życie. Symfonia powstała już dosyć dawno temu, podobnie jak C++ i programowanie zorientowane obiektowo. Od tamtych czasów wiele się zmieniło w podejściu do projektowania programów, a inżynieria oprogramowania jako taka znajduje się w pewnego rodzaju kryzysie. Tzn. na pewno nie można traktować procesu projektowania kodu jako zbioru reguł, których absolutnie musisz przestrzegać. Jeśli czujesz, że jakiś sposób modelowania Twojego programu jest nienaturalny, źle “leży”, to tego nie robisz w ten sposób, nawet jeśli tak kazano w książce. Pracuję jako główny architekt oprogramowania w firmie i jeszcze nigdy nie miałem okazji robić takich szczegółowych tabelek jak Ty tu podałeś. Zwłaszcza nie ma sensu pisać rzeczy, które się powtarzają. Jeśli nie wiesz, do czego coś jest potrzebne, to na razie tego nie rób. Być może przyjdzie taki moment, że samo wyjdzie, że było potrzebne i zrozumiesz.
Na Twoim miejscu ograniczyłbym się do określenia KLUCZOWYCH klas w Twoim programie i ustalenia zakresu ich odpowiedzialności. Jeśli chodzi o powiązania między klasami, to raczej szukałbym WZORCÓW projektowych, które się powtarzają w wielu projektach, i które dałoby się tu sensownie zaaplikować. Oczywiście NIE MA sztywnych reguł w stosowaniu wzorców - tego człowiek się uczy całe życie, jak napisze 10 dużych systemów, zobaczy, jakie są problemy (zawsze jakieś są), to ma doświadczenie i kolejne projektuje lepiej.
BTW: projektowanie dużych aplikacji jest sztuką. Nie da się tego nauczyć z książek. Można co najwyżej czerpać inspirację z książek i cudzych projektów. Sugeruję też poczytać co nieco o metodykach agile, bo to nieco inne podejście niż “projektujemy wszystko od razu”, coraz szerzej stosowane.
Czytam Symfonię z 2006 r. - to chyba nie tak dawno ?
No właśnie zrobiłem to, jeszcze zrobiłem też etap 1 - czyli co po kolei się gdzie dzieje. To mi bardzo pomaga teraz przy pisaniu, ale i tak prawie cała wewnętrzna implementacja się zmieniła. Co do relacji to sobie je jednak oszczędziłem.
Duża aplikacja to ile linijek kodu ? Gdzieś pow. 3 tysięcy ? A jakie książki byś polecił, żeby je przeglądnąć ? Znalazłem o Agile taką:
z sierpnia 2009r. czyli nowiutka, ale znowu tam jest pełno informacji odnośnie firm, których na razie nie potrzebuję - no chyba, że i tak warto ją przeczytać ? Którą byś polecił, to może wypożyczę
3k to jest bardzo mała aplikacja Widziałem pliki źródłowe mające więcej niż 3k SLOC. Przy pisaniu takich aplikacji mało kiedy projektuje się kod(sam tak kiedyś robiłem) bo to tylko strata czasu. Dla ćwiczeń można się trochę pobawić, ale IMO jest to niepotrzebne. Prościej byłoby zrobić reverseengineering niż to zaprojektować.
W początkowych stadiach projektów(tworzonych samodzielnie), gdy jeszcze nie mamy całej koncepcji jak to będzie wyglądać najlepiej usiąść do kodu i go po prostu pisać. Jeśli nam się zmieni koncepcja to będziemy musieli zmienić tylko kod. Gdy uznamy, że taki interfejs a nie inny nam odpowiada to możemy sobie zrobić projekt klas(polecam UML), ale ja osobiście bym tego nie robił.
A mógłbyś wytłumaczyć na jakimś przykładzie w miarę prostym czym te książki się różnią ? Bo dalej nie zauważam różnic po przeczytaniu o wzorcach projektowych na Wiki…
Co do pierwszej książki - jeśli jest to książka o projektowaniu obiektowym to pewnie nie opisuje OO programowania (chyba, że dla niektórych to jedno i to samo) - ale nawet jeśli, to chyba nie jest to mała przeszkoda, co :?: Przy OO programowaniu wystarczy tylko zrobić hierarchie klas, wg mnie…
Programowanie obiektowe to w j. angielskim Object-Oriented Programming czyli OOP Przy programowaniu obiektowym nie wystarczy zrobić hierarchii klas, trzeba też ich używać rozważnie.
Książki z serii “Head First” są podobno(relacja znajomego) napisane bardzo przystępnym językiem i potrafią zaciekawić. Nie miałem okazji ich czytać, ale w najbliższej przyszłości prawdopodobnie jakąś kupię(wzorce projektowe).
Nie rozumiem… Przeczytałem, gdzieś w jakimś kursie, że programowanie obiektowe to obiekty, a programowanie OO to programowanie obiektowe + dziedziczenie i funkcje wirtualne. W tym kursie autor wspominał, że te dwie nazwy są często mylone w Polsce. Zresztą, to samo było w Symfonii napisane, o ile dobrze pamiętam. Więc w końcu jak jest - Programowanie obiektowe = Programowanie OO czy nie :?:
Powracając do książek, to może mi ktoś powiedzieć na przykładzie prostym czym się różnią te dwie książki :?: Tzn. wzorce projektowe od projektowania programu obiektowego…
Przecież na stronie Helionu, dla każdej książki, w sekcji “Informacje dodatkowe” zawsze jest link pt. “Czytaj fragment książki”, który prowadzi do pliku PDF z jednym rozdziałem książki. Polecam ściągnąć i przekonać się samemu
Jakiś dziwny ten kurs, przecież dziedziczenie i polimorfizm to podstawowe cechy programowania obiektowego.
Programowanie obiektowe = Object-oriented programming i tyle.
Okładką, autorami, treścią, omawianymi zagadnieniami. Jednakowa jest część tytułu, wydawnictwo i język, w którym napisane są przykłady.
Analiza i projektowanie zorientowane obiektowo polegają na stworzeniu modelu reprezentującego jakiś fragment rzeczywistości zgodnie z obiektowym paradygmatem programowania. Czyli wyznaczenie aktorów systemu, danych, z których system korzysta, dalej klas, powiązań między nimi, zmian ich stanów, przejść między nimi, itd. Dopiero potem projekt ten może zostać zaimplementowany w jakimś języku programowania.
Natomiast wzorce projektowe to zestaw dobrych i sprawdzonych sposobów rozwiązywania częstych w programowaniu obiektowym zagadnień, związanych z współpracą klas między sobą, tworzeniem obiektów, itd.
Czym innym jest określenie, że nasz system ma posiadać klasy Magazyn i Centrala, a czym innym określenie, że w celu poinformowania Centrali o dostawie nowego towaru do Magazynu zostanie wykorzystany wzorzec Obserwator.
Wiem, że jest, ale go nie czytałem z wielu powodów
OOP to programowanie obiektowe a to o czym mówisz to programowanie bazujące na obiektach(object based) które jest wyjaśnione w Symfonii. Nie wiem dlaczego autor przyrównał programowanie bazujące na obiektach do programowania obiektowego ale to wg mnie(i raczej nie tylko mnie) jest(był) błąd.
Hmmm, to chyba wybiorę tą książkę o projektowaniu programów obiektowych, jeżeli tam przykłady nie są pisane w Javie… Nie mogę tego na razie sprawdzić, bo “Czytaj przykładowy rozdział” nie działa na razie. We wzorcach przykłady niestety są w tym języku, a ja go jeszcze nie znam…
Widziałem pliki źródłowe mające więcej niż 3k SLOC. Przy pisaniu takich aplikacji mało kiedy projektuje się kod(sam tak kiedyś robiłem) bo to tylko strata czasu. Dla ćwiczeń można się trochę pobawić, ale IMO jest to niepotrzebne. Prościej byłoby zrobić reverseengineering niż to zaprojektować.
