PO Wprowadzenie do programowania obiektowego

Wprowadzenie

Na pierwszym wykładzie omówione zostało czym są i jak odnajdywać klasy pojęciowe. Przypomnijmy, że rozpoznanie klas pojęciowych pozwala lepiej zrozumieć dziedzinę problemu. Na tym wykładzie pokażemy, że myślenie obiektowe ułatwia tworzenie programów i wyjąśnimy co wyróżnia obiektowe języki programowania. Pokażemy również, że odnajdywanie klas pojęciowych nie było jedynie ćwiczeniem. Będzie się można na nich wzorować podczas projektowania i tworzenia programu, jednocześnie zmiejszając lukę reprezentacji.

Obiekty, a programowanie

Rozpoczęliśmy tworzenie modelu obiektowego i dzięki temu lepiej rozumiemy dziedzinę. Oczywiście nasz model nie jest od razu kompletny, ale warto się na nim wzorować podczas projektowania programu do gry w Monopol i tym samym ograniczyć lukę reprezentacji. Patrząc na diagramy ze stanem poszczególnych obiektów nie trudno o porównanie klas do rekordów, atrybutów do pól rekordów. To dobre skojarzenia. W językach obiektowych klasy rzeczywiście pełnią rolę typów danych, a obiekty są wartościami tych typów. Prawdziwą rewolucję podejście obiektowe wprowadza jednak dopiero w sposobie organizacji kodu operującego na tych danych. Jest on również zebrany w klasach. Czyli dane i kod na nich operujący są razem! Kod w każdej klasie jest podzielony na metody, które wywołuje się na rzecz jakiegoś egzemplarza. Metody mogą mieć parametry i zwracać jakieś wartości. Ponadto mają bezpośredni dostęp do danych egzemplarza na rzecz którego są wykonywane oraz mogą te dane modyfikować. Na poniższym diagramie widać klasę Kostka wraz z jej metodami wymienionymi w trzeciej przegródce. Metoda losujWartość() nie ma żadnych parametrów i nie zwraca żadnej wartości. Z jej nazwy można się domyślać, że powinna wylosować nową wartość atrybutu wskazywanaWartość. Metoda getWartość() : Integer również jest bezparametrowa, ale zwraca wartość będącą obiektem klasy Integer. Z jej nazwy można się domyślać, że zwraca wartość atrybutu wskazywanaWartość. Warto zwrócić uwagę, że dla tego atrybutu również określono, że przechowuje obiekt klasy Integer. Trzy kropki umieszczone w trzecie przegródce po ostatniej metodzie oznaczają, że klasa posiada jeszcze inne metody, ale ich nie pokazano.

Mimo, że na powyższym diagramie użyliśmy tej samej notacji, nie jest to już model dziedziny. Zaczęliśmy projektować oprogramowanie. Wiemy mniej więcej jakie informacje będą przechowywane w poszczególnych klasach. Trzeba określić typy ich atrybutów, zdecydować jak zrealizować powiązania oraz rozdzielić metody.

Po podjęciu tych decyzji i pokazaniu ich na diagramie nie mamy już do czynienia z klasami pojęciowymi, które przedstawiają rzeczywistość, ale z klasami projektowymi (ang. design class), które przedstawiają projekt oprogramowania. Można powiedzieć, że programowanie obiektowe polega na wyznaczaniu obiektom odpowiedzialności. Te odpowiedzialności są dwóch typów: za pamiętanie pewnych danych i za wykonywanie operacji na tych danych. Przy czym to zdecydowanie, które klasy wykonują jakie operacje jest trudniejsze i ważniejsze. Wszystkie szczegóły w jaki sposób obiekty wywiązują się z tych odpowiedzialności są ukryte w definicji klasy. Pozwala to łatwiej zapanować nad złożonością. Pisząc metody danej klasy można się skupić tylko na wycinku całego zadania – na realizacji odpowiedzialności wyznaczonych tej klasie. Jeżeli do wywiązania się z tych odpowiedzialności potrzeba wykonać operacje na danych innych obiektów, po prostu się im te operacje zleca. To tak samo jak w dobrze zorganizowanej firmie, która zatrudnia ekspertów z różnych dziedzin. Każdy obiekt odpowiada za swój kawałek i nie ingeruje w pracę pozostały.