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";
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++.
Analizując wszystkie odpowiedzi, łatwo dostrzec, że tylko destruktor jest logicznym miejscem na informację o usunięciu obiektu, natomiast pozostałe opcje często wynikają z błędnego rozumienia roli metod klasy. Konstruktor, mimo że jest wywoływany przy tworzeniu obiektu, nie ma żadnego związku z jego usuwaniem – to wręcz jego przeciwieństwo. Często spotykam się z sytuacją, gdzie ktoś myli konstruktor z destruktorem, bo oba mają podobną nazwę, ale ich funkcje są dokładnie odwrotne. Operator== z kolei odpowiada za porównywanie obiektów — nie wpływa ani na ich tworzenie, ani usuwanie. Umieszczając tam komunikat o usunięciu, wprowadzilibyśmy tylko zamieszanie i moglibyśmy nawet nie zauważyć, kiedy taki tekst się pojawia – bo wywołanie operatora porównania może następować wiele razy, a obiekt nadal będzie istniał. Statyczna metoda wypisz również nie ma żadnej relacji z cyklem życia instancji danej klasy – jej zadaniem jest operowanie na danych klasy jako takiej, a nie konkretnych obiektach. W praktyce, próba umieszczenia kodu diagnostycznego związanego z usuwaniem obiektu w którejkolwiek z tych metod może prowadzić do powstania nieczytelnego, trudnego w utrzymaniu kodu i błędnej interpretacji działania programu. Wielu programistów na początku swojej kariery ulega pokusie wrzucania komunikatów wszędzie, gdzie popadnie, ale z czasem przekonują się, że konstruktor i destruktor mają swoje jasno określone role i to właśnie destruktor jest miejscem na komunikaty o końcu życia obiektu. Standardy branżowe i literatura (jak np. Meyers czy Sutter) mocno podkreślają, żeby rozdzielać odpowiedzialności i nie zaciemniać logiki klasy niepotrzebnymi wywołaniami w niewłaściwych miejscach.