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 i ich stan

Po stworzeniu modelu dziedziny dla gry w Monopol, można przyjrzeć się jakiejś rozgrywanej grze i wypisać wszytkie obiekty wraz z wartościami ich atrybutów. Wartości atrybutów pojedynczego obiektu określają jego stan. A stany wszystkich obiektów składają się w sumie na stan gry. Dotychczas na diagramach pokazywaliśmy jedynie klasy. Używając tej samej notacji można pokazywać poszczególne obiekty wraz z ich stanem.

Na powyższym diagramie widać trzy obiekty klasy Gracz oraz wartości ich atrybutów. Pierwsza przegródka zawiera etykietę składającą się z identyfikatora obiektu i występującą po dwukropku nazwę klasy. Cała etykieta musi być obowiązkowo podkreślona. Identyfikator można opuścić, ale jego podanie ułatwia odwoływanie się do tego obiektu. W drugiej przegródce wymienione są kolejne atrybuty oraz po znaku "=" ich wartości. Ten przykład pokazuje również jak na diagramach umieszczać komentarze tekstowe. Służą do tego notatki (ang. note) przedstawiane jako prostokąt z zagiętym prawym górnym rogiem. Notatki dołącza się do opisywanych przez nie elementów przy pomocy przerywanej linii.

Wiązania

Godne uwagi związki pomiędzy obiektami pokazujemy w ten sam sposób co powiązania między klasami. Przyjęło się je nazywać wiązaniami (ang. link). Tak samo jak obiekty są egzemplarzami klas, wziązania można uznać za egzemplarze powiązań. Poniższy diagram pokazuje wiązanie między obiektami klas Gracz i Pionek.

Obiekty, a programowanie

Rozpoczeliś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, tym samym ograniczając 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, a wiązań do wskaźników. To dobre skojarzenia. Klasy rzeczywiście można potraktować jako typy danych, a obiekty jako wartości tych typów. Rewolucję programowanie obiektowe wprowadza dopiero w sposobie organizacji kodu operującego na tych danych. Jest on również zebrany w klasie. 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ś egzamplarza. Metody mogą mieć parametry i zwracać jakieś wartości. Ponadto mają bezpośredni dostęp do danych egzamplarza 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.

Od chwili kiedy decydujemy się pokazywać metody i typy atrybutów nie jest to już klasa pojęciowe, tylko klasa projektowa (ang. design class).