Podręcznik

Zacznijmy od tego, że w przypadku programowania obiektowego program składa się z obiektów, które wchodzą w interakcje, przesyłając sobie nawzajem komunikaty / wykonując pewne działania.

Na początek zwykle najłatwiej jest wyobrazić sobie obiekt jako żywą istotę. Obiekty mają coś, co wiedzą (atrybuty, pola), oraz coś, co mogą zrobić (zachowania lub operacje). Wartości atrybutów obiektu określają jego stan, poprzez wywoływanie zachowań obiekty przechodzą od stanu do stanu.

Tutaj warto byśmy na chwilę zatrzymali się przy terminologii. W programowaniu strukturalnym mówiliśmy zazwyczaj o zmiennych - jako o czymś, w czym można przechowywać wartość jakiegoś typu. W przypadku programowania obiektowego - sam obiekt jest zmienną złożoną. Natomiast zazwyczaj nie mówimy że składa się ze zmiennych - tylko używamy tu pojęcia pola lub (zamiennnie) atrybuty - czyli nazwaną część obiektu która może przechowywać wartości jakiegoś typu. W programowaniu strukturalnym mówiliśmy także o funkcjach. Jeśli funkcję powiążemy z obiektami określonego typu, i jeden z nich przypiszemy do niej jako kontekst wykonania - to nazwiemy ją metodą. 

Klasy to "plany" obiektów. Klasa łączy atrybuty (pola) oraz zachowania (metody lub funkcje) w jedną odrębną jednostkę, opisuje ją syntaktycznie i definiuje zachowania. Z tego punktu widzenia obiekty są egzemplarzami (instancjami) klas.

Obiekt

Mówiąc bardziej formalnie, obiekt jest strukturą danych, występującą łącznie z operacjami dozwolonymi do wykonania na niej (do tej pory zajmowaliście się strukturami, definiowanymi przez struct które nie miały bezpośredniej łączności składniowej z dozwolonymi operacjami). Obiekt może być złożony, a więc może składać się z innych obiektów. Każdy obiekt ma przypisany typ, tj. wyrażenie językowe, które określa jego budowę (poprzez specyfikację pól) oraz ogranicza kontekst, w którym odwołanie do obiektu może być użyte w programie.

Obiekt może być powiązany z innymi obiektami związkami skojarzeniowymi, odpowiadającymi relacjom zachodzącym między odpowiednimi bytami w dziedzinie problemowej. Inaczej mówiąc – obiekty mogą wiedzieć o innych obiektach, korzystać z nich czy też zarządzać nimi (składać się z nich). Zazwyczaj dąży się do tego, by relacje między obiektami w kodzie programu odpowiadały naturalnym relacjom między obiektami w świecie rzeczywistym, np. pisząc symulator samochodu, i tworząc obiekt typu samochód i obiekt typu silnik, dbamy o to, by to samochód zawierał silnik.

Dodatkowo, sam obiekt można charakteryzować korzystając z następujących pojęć:

• Każdy obiekt ma stan – czyli komplet aktualnych wartości wszystkich jego pól. Stan obiektu zmienia się w czasie – bo można zmieniać wartości jego pól, można też modyfikować powiązania obiektu z innymi obiektami.
• Oprócz stanu – każdy obiekt jest charakteryzowany przez tożsamość, która odróżnia go od innych obiektów. W praktyce tożsamości odpowiada adres w pamięci w którym obiekt jest przechowywany, lecz z funkcjonalnego punktu widzenia tożsamość odróżnia nam obiekty identyczne (będące w tym samym stanie) – tak jak w przypadku jednojajowych bliźniaków – są identyczni, lecz każdy z nich jest inną osobą. Podobnie jest z obiektami – mogą mieć wszystkie wartości swoich atrybutów równe sobie, lecz nie być tym samym obiektem.

Klasa

Klasa to szablon obiektu - jest miejscem przechowywania tych własności grupy obiektów, które są niezmienne dla wszystkich członków grupy. W klasach zdefiniowane są ciała metod - bo metody są wspólne dla wszystkch obiektów. Zdefiniowane są także typy pól -bo wszystkie obiekty tej samej klasy mają takie same pola. Natomiast w klasach nie ma wartości pól - wartości są stanem przypisanym do konkretnego obiektu. Klasa też nie mia tożsamości w sensie takim jak ma ją obiekt - nie ma swojej reprezentacji jako zmienna w pamięci. 

Dobrze zbudowana klasa jest starannie wydzieloną abstrakcją pochodzącą ze słownictwa dziedziny danego problemu lub rozwiązania. Zazwyczaj klasa powinna opisywać coś, co w pełni rozumiemy, i rzeczywiście pojawia się w opisie problemu, najczęściej jako rzeczownik. Klasa obejmuje pewien mały, dobrze określony zbiór zobowiązań, z których jest w stanie się w pełni wywiązać, doświadczeni programiści czasami twierdzą, że jeśli odpowiedzialności danej klasy nie da się zapisać na małej, żółtej karteczce – to znaczy że powinna być ona podzielona na mniejsze części. Mówiąc dalej językiem teorii informatyki – klasa zapewnia oddzielenie specyfikacji abstrakcji od jej implementacji. Jest zrozumiała i prosta, a przy tym rozszerzalna i dająca się łatwo dostosować do potrzeb (ech ... piękna idea ;) ).

To wszystko brzmi ciągle nieco abstrakcyjnie, więc może prosty przykład: Wyobraźcie sobie prostokąt:

Prostokąt ma pola różnego typu logicznie powiązane ze sobą – rozmiar, kolor położenie. Powiązaniem logicznym jest to, że i rozmiar, i położenie opisują jeden konkretny prostokąt. W programie komputerowym prostokąt może również pewne czynności “wykonać” - narysować się, przesunąć, zmienić rozmiar. I to jest właśnie obiekt.

Jeśli natomiast weźmiemy pod uwagę wiele prostokątów:

Możemy zauważyć, że każdy z nich ma kolor (inny co do wartości, lecz tego samego typu), każdy ma rozmiar (podobnie – typ ten sam, różne wartości), każdy możemy narysować (mechanizm jest ten sam, różni się jedynie kolor, pozycja gdzie jest rysowany, rozmiar, itp.). Czyli istnieje pewien szablon, pozbawiony tożsamości i stanu opis prostokąta, nie jednego konkretnego, lecz każdego możliwego prostokąta. I to jest klasa, w dodatku dobrze zdefiniowana. Reprezentuje byt z dziedziny problemu, i jest zrozumiała. Jej odpowiedzialność także da się streścić w jednym zdaniu – odpowiada za przechowywanie wszystkich danych oraz operacji pozwalających na narysowanie na ekranie prostokąta.