W programowaniu obiektowym (OOP) klasa jest definicją (szablonem/typem), która opisuje, jakie dane (pola/atrybuty) i zachowania (metody) mają posiadać tworzone na jej podstawie byty. Obiekt to konkretna instancja klasy, czyli utworzony w czasie działania programu egzemplarz mający własny stan (wartości pól) i dostęp do metod zdefiniowanych w klasie.
Dlatego odpowiedź "Obiekt jest reprezentantem klasy." jest poprawna: obiekt "reprezentuje" klasę jako konkretny egzemplarz powstały z jej definicji. W wielu materiałach spotkasz równoważne sformułowania: "obiekt jest instancją klasy".
Dlaczego pozostałe stwierdzenia są niepoprawne?
- "Zastosowanie obiektu wyklucza użycie klasy." – w klasycznym OOP obiekty najczęściej powstają właśnie na podstawie klas. Używanie obiektów zwykle zakłada istnienie klas (pomijając szczególne mechanizmy prototypowania w niektórych językach).
- "Klasa jest częścią składową obiektu." – relacja jest odwrotna: obiekt jest tworzony na podstawie klasy. Obiekt może przechowywać referencję do swojej klasy (zależnie od języka/implementacji), ale nie oznacza to, że klasa jest "częścią" obiektu w sensie składowej jak pole danych.
- "Pojęcia obiekt i klasa można stosować zamiennie." – nie można, bo klasa to opis typu, a obiekt to konkretny egzemplarz. Zamienne używanie tych pojęć prowadzi do błędów projektowych i implementacyjnych (np. mylenia definicji z danymi runtime).
W praktyce egzaminacyjnej warto zapamiętać: klasa = przepis, obiekt = potrawa. Przepis opisuje, jak coś zrobić, a potrawa jest konkretnym wynikiem – tak jak obiekt jest konkretną instancją klasy.
