Kwalifikacja: INF.04 - Projektowanie, programowanie i testowanie aplikacji
Zawód: Technik programista
Kategorie: Programowanie Projektowanie aplikacji
W obrębie klasy pracownik zdefiniowano następujące metody:
pracownik() { ... }
static void wypisz() { ... }
int operator== (const pracownik &prac) { ... }
~pracownik() { ... }
Którą z nich można, zgodnie z jej funkcją, rozszerzyć o element diagnostyczny o treści:
cout << "Obiekt został usunięty";
Odpowiedzi
Informacja zwrotna
Wybranie destruktora ~pracownik do umieszczenia komunikatu diagnostycznego o usunięciu obiektu jest jak najbardziej słuszne i zgodne z praktykami programowania obiektowego w C++. To właśnie destruktor odpowiada za wykonywanie wszelkich czynności „na pożegnanie” obiektu, czyli w momencie jego zwalniania z pamięci. Właśnie tu umieszcza się takie rzeczy jak logowanie faktu usunięcia, czyszczenie zasobów zewnętrznych czy zwalnianie pamięci dynamicznej. W praktyce, gdy zadeklarujemy cout << "Obiekt został usunięty"; w destruktorze, będziemy mieli jasny sygnał przy każdym końcu życia obiektu, co świetnie nadaje się do diagnostyki i szukania błędów w zarządzaniu pamięcią. Moim zdaniem każdy programista, nawet początkujący, powinien chwilę pobawić się takimi komunikatami, żeby lepiej zrozumieć, kiedy dokładnie destruktor jest wołany (np. przy wyjściu ze scope’u, delete, końcu programu itp.). To też dobry sposób, żeby wychwycić niechciane wycieki pamięci lub zrozumieć, dlaczego obiekt nie został jeszcze usunięty. Wzorce projektowe, takie jak RAII, wręcz opierają się na działaniu destruktorów. W branży często stosuje się podobne rozwiązania do debugowania problematycznych fragmentów kodu. Ogólnie rzecz biorąc, umieszczanie komunikatów w destruktorze jest praktycznym i polecanym sposobem na rozpoznanie cyklu życia obiektu – i to w każdej większej aplikacji C++.