Archiwa tagu: obiekt

Klasy i obiekty – trochę teorii

Dodaj komentarz

Rodzaje relacji pomiędzy obiektami:

  • powiązanie – luźna relacja, mówiąca tylko o współdziałaniu obiektów
  • agregacja – silna forma powiązania obiektów.
  • skojarzenie
  • generalizacja – służy do wyrażania podobieństwa pomiędzy obiektami
  • dziedziczenie – doskonale znane z programowania. Pozwala elementom bardziej szczegółowym wykorzystywać strukturę obiektów bardziej ogólnych.

Własności obiektów:

  • atrybut – struktura danych, która opisuje jakąś cechę obiektu (np. string backgroundColor = '#FF00FF';).
    Przyjmowane wartości są ściśle określone poprzez typ danych (np. integer).
    Jeżeli mamy sytuację, że wartością miałby być inny obiekt, to wtedy wartością atrybutu nie jest ten obiekt, lecz wskazanie na obiekt (powiązanie). Dobrze widać to na przykładzie języka C++. Atrybutami są typy proste (int, float itd.), natomiast chcąc mieć w klasie bardziej rozbudowany obiekt, umieszczamy de facto wskaźnik do niego.
  • usługa – (abstrakcyjne pojęcie) zachowanie obiektu, funkcjonalność jaką musi dostarczyć obiekt (powiedziałabym, że interfejs definiuje nam usługi, a klasa będzie je implementować w metodach). Jest opisywana przez sygnaturę – ilość raz typy parametrów, zwracany wynik.
  • metoda – implementacja usługi. Wiązanie metod do usług może być realizowane na różne sposoby (np. dziedzicząca klasa może nadpisywać metodę zdefiniowaną w klasie wyżej itp.)
  • stan – stan obiektu w danej chwili, zapisane w atrybutach wartości, które wpływają  na sposób zachowania się obiektu. Zmienia się na skutek wywołania metod (np. ustawienie atrybutu albo wykonanie na nim jakiś obliczeń) lub samoistnej zmiany.
  • komunikat – zlecenie wykonania usługi + parametry (czyli de facto wywołanie metody).

Definicje – projektowanie obiektowe

1 odpowiedź

Przy okazji sprzątania biurka ze szpargałów ze studiów, wpadły mi w ręce całkiem zgrabne wykłady na temat projektowania obiektowego (czyli – planowania jak wykonać i zaprogramować projekt, np. za pomocą diagramów UML). Może przyda się – jako szybka powtórka pojęć, które każdy programista „obiektowy” znać powinien.

(Podejście momentami niestety dość suche i akademickie, wpis chciałabym więc sukcesywnie uzupełniać o bardziej „ludzkie” definicje.)

Interfejs – klasa bez atrybutów, nie opisująca implementacji metod, posiadająca wyłącznie usługi i operacje abstrakcyjne.

Abstrakcja – pomijanie nieistotnych szczegółów w celu ukazania tych informacji, które są w danym przypadku istotne. W połączeniu ze skalą (czyli „taką organizacją, aby dowolnie duża wartość była przejrzysta dla obserwatora”) można sobie wyobrazić to jako schemat blokowy (lub UML) – ogólny gdy jest „oddalony”, a w miarę zwiększania skali – bardziej szczegółowy. Zgodnie z zasadą skali, logicznie powiązane klasy powinny znajdywać się w jednym pakiecie.

Hermetyzacja – ukrywanie szczegółów implementacji za interfejsami, aby dana „struktura” (klasa, moduł, pakiet, biblioteka…) zamykała w sobie możliwie jedną funkcjonalność.
Interfejsy powinny ukrywać jak najwięcej szczegółów implementacyjnych (czyli lepiej, aby posiadały jedną metodę typu „rób to”, niż kilka metod, konfiguracji, kilka metod wykonania danej czynności – programista implementujący taki interfejs w swojej klasie poczuje się zdezorientowany).
Dane oraz operujące na nich algorytmy powinno zostać umieszczone w jednym obiekcie.
Wartości atrybutów powinny zostać udostępniane tylko przez usługi (gettery, settery albo bardziej rozbudowane metody), dzięki czemu można go z zewnątrz pobrać, a niekoniecznie można go modyfikować.
Hermetyzacja powoduje duże rozdrobnienie struktury, ponieważ każda klasa zajmuje się jedną rzeczą.

Czytaj dalej →