Najprzyjemniejszym etapem programowania obiektowo orientowanego jest samo projektowanie programu.

Przypomnij sobie jak to było do tej pory. Siadałeś przed monitorem, uruchamiałeś edytor i zaczynałeś pisać program wystukując kolejne instrukcje wprost na klawiaturze. Najpierw zaczynałeś pisać segment główny programu (w języku C jest to funkcja main). To, co miałeś zaprogramować rozbijałeś na proste czynności, z których robiłeś funkcje. To było właściwie kwintesencją programowania - napisanie określonej liczby funkcji, wywoływanych w określonym porządku.

Z programowaniem OO tak się nie da. Nie można usiąść przed monitorem i a vista pisać program. Trzeba sobie ten program najpierw obmyślić.

"-Eeee" - pomyślałeś sobie zapewne - "miało być wspaniałe narzędzie, a tymczasem już utrudnienia..."

Nie zniechęcaj się. Oczywiście, że możesz od razu zasiąść przed monitorem i pisać, tylko że to, co napiszesz będzie trochę pokraczne. - Tak jakbyś chcąc budować dom poszedł od razu na plac budowy i zaczął murować. To, co zbudujesz, domem mimo wszystko będzie. Jednak będzie pokraczne. Każdy wie, że lepiej najpierw narysować sobie projekt tego domu. Podobnie z programowaniem.

Ten etap obmyślania programu (projektowania) dostarcza naprawdę dobrej zabawy. Tak, jak krawiec artysta cieszy się najbardziej, gdy projektuje. Natomiast wtedy, gdy siada do maszyny by uszyć - to już nie jest takie podniecające. Po prostu rzemiosło.

Porozmawiajmy teraz właśnie o projektowaniu

Ironia losu polega na tym, że na etapie projektowania programu musi walczyć z naszymi dotychczasowymi nawykami z tradycyjnych technik programowania. Natomiast ktoś, kto nigdy nie programował - technikę OO uzna za zupełnie oczywistą. Oto dlaczego:

Pisany program zawsze odnosi się jakoś do zjawisk w świecie realnym. Jeśli jest to program do księgowania - odzwierciedla obiekty i metodykę pracy księgowego. Są czeki, faktury, kasa, konta. Z kolei program, który służy do gry w Chińczyka - operuje takimi obiektami jak pionki, plansza, kostka do gry. W programie sterującym promem kosmicznym, obiektami są poszczególne podzespoły, którymi trzeba w określony sposób sterować.

W sytuacji, gdy posługujemy się tradycyjnymi metodami programowania - musimy ten wycinek świata realnego zapisać jakoś w komputerze. Rozbija się więc wszystko na luźne liczby, na których później pracuje program. Programowanie wówczas polega na - mówiąc obrazowo - wydawaniu poleceń małpie, którą nauczono dodawać. Mówi się: "a teraz dodaj tę liczbę do tamtej i rezultat umieść tutaj". Aby w ten sposób sterować promem kosmicznym - trzeba się bardzo natrudzić.

Projektowanie obiektowo orientowane opiera się na innej idei. Jeśli program zajmuje się jakimiś obiektami i zjawiskami ze świata rzeczywistego, to nie rozbijamy tego wszystkiego na luźne liczby. Budujemy model. W programie tworzymy modele rzeczywistych obiektów. Tak zbudowane obiekty wyposażone są nie tylko w dane, ale także w zachowanie.

Mój przyjaciel Dirk Fischer mówi, że wykonywanie programu OO przypomina mu party, na które zaproszono wiele różnych obiektów. Obiekty te chodzą, rozmawiają ze sobą, załatwiają ze sobą różne sprawy. Każdy obiekt ma swój stan wewnętrzny - polegający na grubości swojego portfela lub ilości wypitej whiski. Obiekty mają też swoje określone zachowania - ktoś jest kelnerem serwującym drinki, ktoś jest bardzo ważną osobą, ktoś jest gospodarzem. O stanie wewnętrznym obiektów nie można dowiedzieć się wprost (private!), ale można to wywnioskować z rozmowy z takim obiektem. Napisanie programu obiektowo orientowanego polega na zorganizowaniu takiego party.

Podkreślmy jeszcze raz: projektowanie programu OO polega na modelowaniu. W komputerze buduje się model zagadnienia, którego dotyczy program.

Jeżeli chcemy nauczyć się nowego języka programowania - to sprawa nie jest trudna. Zawsze jest jakaś pętla do, pętla for, instrukcja if. Nauka polega tylko na uchwyceniu tych niewielkich różnic w składni powyższych instrukcji.

Jeśli zdarzyło Ci się kiedyś tłumaczyć program z Pascala na C - to przyznasz mi chyba rację. Jest to dość łatwe: instrukcje tłumaczy się - że tak powiem - w skali 1:1. Tu w Pascalu jest tak zapisana pętla for - to w języku C zapisuję ją w taki-a-taki sposób.

Przejście od programu w C do obiektowo orientowanego programu w C++, to już nie tłumaczenie 1:1. Pojawia się nowa technika programowania - zatem trzeba zmienić sposób rozumowania, sposób patrzenia na rozwiązania danego problemu. Na szczęście przy technice OO proponuję Ci zmianę sposobu patrzenia na bardziej naturalny - taki, jakim posługujesz się na co dzień w życiu. Inaczej mówiąc program OO nie jest w stosunku 1:1 do programu tradycyjnego. On jest w stosunku 1:1 do rzeczywistości.

Praktyczne wskazówki dotyczące pojektowania programu techniką OO

Pracę nad programem można podzielić na następujące fazy:

- Rozpoznanie problemu

- Projektowanie programu

- Implementacja (kodowanie)

- Testowanie

Najpierw należy zapoznać się z zagadnieniem i zrozumieć je - to faza rozpoznania. Następnie wiedząc co mamy zrobić projektujemy program. Kolejna faza to implementacja, czyli moment właściwego kodowania programu (np. w języku C++). Potem następuje testowanie. Testowanie - jak powszechnie wiadomo - nie wieńczy dzieła. Najczęściej okazuje się, że trzeba wrócić i coś przeprojektować lub nawet lepiej zrozumieć, bo nastąpiło nieporozumienie, albo zamawiający program zażądał dodatkowych modyfikacji. Praca nad programem odbywa się metodą kolejnych przybliżeń.

Prześledźmy teraz dokładniej kolejne fazy pracy nad programem.

Rekonesans - czyli rozpoznanie zagadnienia

Dowcipni twierdzą, że praca nad programem zaczyna się wtedy, gdy szef lub klient przychodzi do Ciebie i - machając rękami oraz bardzo dużo i niezrozumiale mówiąc - wysuwa serię dziwacznych żądań. W tym momencie przystąpić trzeba do rozpoznania zagadnienia.

Jest to sztuka sama w sobie, wkraczająca niemal w psychologię - nie możemy tutaj dłużej się nad tym zatrzymywać. W skrócie powiem tylko, że jeśli klient jest nerwowy, to sadzamy go w wygodnym fotelu i nie dopuszczamy, by z niego wstawał. Następnie zadajemy mu proste pytania, które zmuszą go do udzielenia prostych odpowiedzi. Metodą takich pytań po dłuższym czsie dochodzimy do tego, co program ma robić i w jaki sposób.

A teraz uwaga: jeśli klient powie, że program ma spełniać takie-a-takie warunki, ale liczyć się należy, że w przyszłości będzie musiał spełniać inne, nieznane jeszcze dzisiaj - to jest to sygnał, że program musisz napisać w języku obiektowo orientowanym (np. w C++).

Jeśli tak nie powie, to oczywiście też możesz pisać techniką OO bo:

1) lubisz ten nowoczesny styl programowania

2) znasz klientów i wiesz, że za miesiąc zmieniają zdanie i już wtedy będą potrzebne modyfikacje.

To wszystko, co opowiedział klient o jakimś swoim zagadnieniu, które należy oprogramować - ten kawałek rzeczywistości, którym zająć się ma program - to nazywać się będzie systemem. Księgowość danej firmy to jakiś system. Gra w ćhińczyka to także jakiś system.

Chodzi więc o rozpoznanie systemu. Takie rozpoznanie już kiedyś zapewne w życiu przeprowadzałeś - wtedy, gdy ktoś uczył Cię w tego Chińczyka grać. Ktoś Ci to zawile tłumaczył, Ty zadawałeś proste pytania po to, by jego skomplikowaną wypowiedź uprościć. Co jakiś czas upewniałeś się, czy dobrze zrozumiałeś dany fragment. Dodatkowo jeszcze przyjrzałeś się, jak grają w tego Chińczyka inni. Suma tych działań stanowiła dla Ciebie rozpoznanie tego systemu.

Nie inaczej jest w wypadku rozpoznawania poważnego systemu - księgowości, sterowania samolotem, czy systemu kontrolującego aparaturę elektroniczną w eksperymencie fizycznym.

Dopiero, gdy rozpoznamy system - możemy przystąpić do projektowania. Możesz być jednak pewien, że jeszcze powrócisz do tego etapu. Wcześniej czy później okaże się, że czegoś dokładnie nie zrozumiałeś. Nic w tym złego. To jest wkalkulowane w metodę.