Implementacja TObject      Strona 3 z 9        Dalej
w oparciu o materiały ze stron BytaminC

       Enkapsulacja

      Inaczej jest to ukrywanie danych. Umieszczając kod obsługujący dane razem z nimi, dane nie potrzebują już być dostępne dla innego kodu. Możesz teraz kontrolować dane i blokować dostęp do nich.

      Nie musisz dokonywać enkapsulacji danych, ale powinieneś to robić. Dlaczego? Teoretycznie, kiedy tworzysz obiekt, zapewniasz mu wszystkie metody konieczne do modyfikacji i obsługi danych. Kiedy inny programista będzie chciał użyć Twojego obiektu, nie musi nic wiedzieć o jego wewnętrznej budowie. Enkapsulacja danych prowadzi do łatwiejszego ponownego wykorzystania kodu.

      Jedna mała uwaga; ponieważ zmienne const (stałe) nie mogą być zmieniane, nie powinieneś dokonywać ich enkapsulacji.

      Dziedziczenie

      To chyba najważniejsza część OOP. Kiedy tworzysz nową klasę wybierasz punkt wyjścia dla Twojego obiektu. Jest to potężne narzędzie używane w ponownym wykorzystaniu kodu. Jeżeli istnieje obiekt podobny do tego, który tworzysz, to możesz po prostu dziedziczyć z niego i dodać kilka właściwości, albo zmienić kilka.

      Na przykład, jeżeli istniałby obiekt przetrzymujący dane i metody dla studentów, mógłbyś z niego dziedziczyć i dodać dodatkowe metody i dane, tak, żeby był unikalny dla konkretnego kierunku /major/. Wszystkie dotychczasowe metody nadal funkcjonowałyby, chyba, że wymieniłbyś je na inne specyficzne dla danego kierunku. Oto diagram, pokazujący jak to by wyglądało:



      W tym przykładzie Computer Engineer Major ma wszystkie cechy Sciences Major i Basic Student.

      Chociaż dziedziczenie jest wartościową cechą OOP, to zauważysz na pewno, że niektóre nowe klasy nie mają sobie podobnych i w tym przypadku nie będą dziedziczyły żadnych właściwości, będąc w ten sposób klasą podstawową. Pamiętaj, że kiedy dziedziczysz z jakiejś klasy, to możesz do niej dodać nowe funkcje, ale nie odjąć.

      Do określenia relacji pomiędzy obiektami tej samej rodziny użyto kilku dodatkowych określeń. Basic Student jest przodkiem Computer Engineer Major, co oznacza że Basic Student leży wyżej w łańcuchu hierarchii. Inaczej mówiąc Computer Engineer Major jest potomkiem Basic Student.

      Polimorfizm

      Kiedy zajmujesz się obiektami masz do czynienia z wykresem hierarchii. W powyższym przykładzie Computer Engineer Major ma wszystkie właściwości i metody, które można znaleźć w Sciences Major i Basic Student. Interesującą rzeczą jest to, że możesz "zobaczyć" klasę w każdym punkcie, który stoi niżej w łańcuchu hierarchii. Co???

      No dobrze, wyjaśnię dokładniej, ponieważ jest to ważne. Polimorfizm pozwala zredukować ilość kodu do minimum, więc przeczytaj uważnie ten paragraf.

      Z powyższego wykresu, powiedzmy, że potrzebujesz wydrukować listę wszystkich studentów. Kiedy patrzysz na każdego studenta, możesz znaleźć Information Systems Major, Computer Engineer Major, albo jakiś inny kierunek. Przeglądając tą listę możesz nie wiedzieć jaki kierunek będzie następny. Mógłbyś wstępnie posortować kierunki i stworzyć wiele procedur, żeby utworzyć listę, ale rezultatem byłaby duża ilość kodu i wolniejsze przetwarzanie. Chciałbyś, żeby wszystkie kierunki były obsługiwane tą samą logiką. Możesz tego dokonać poprzez polimorfizm.

      Jednym faktem, którego jesteś pewien o studentach jest to, że należą oni wszyscy do kategorii Basic Student. A ponieważ jest to klasa bazowa, wszystkie klasy pochodne będą miały jej właściwości, nawet jeżeli kilka metod, czy też właściwości zostało nadpisanych. Tak więc używając polimorfizmu możesz zobaczyć wszystkich studentów jako Basic Student i zażądać informacji potrzebnej do sporządzenia listy poprzez metody klasy bazowej.

      Aby zmienić obiekt na obiekt innej klasy możesz użyć rzutowania na żądany punkt łańcucha hierarchii. W zasadzie możesz go zobaczyć (reinterpret_cast) albo dokonać konwersji (static_cast albo dynamic_cast). Najważniejszą rzeczą, o której musisz pamiętać jest to, że możesz rzutować w kierunku klasy bazowej, ale nigdy w odwrotnym. To znaczy, nie możesz dokonać konwersji obiektu na potomka tegoż obiektu.

Autor: Scott Cross
Tłumaczenie:  Maciek Frankiewicz

1  2  3  4  5  6  7  8  9