C# Java i Klasa abstrakcyjna : Programistyczna rozmowa kwalifikacyjna

Mind F###Na rozmowach kwalifikacyjnych osoby rekrutujące lubią zadawać podchwytliwe  pytania. Przykładowo  przed każdą rozmową kwalifikacyjną z Javy warto byłoby sobie przypomnieć jak działają metody porównywania napisów.

Ich działanie nie jest takie intuicyjne jak się wydaje.  Oto poniższy przykład. Sprawdź swoją wiedzę i sprawdź czy rozumiesz poniższy przykład.

public static void main(String[] args) {
    String a1 = "something", a2 = "maybe something else";
    System.out.print(a1 == a2);      // Legal, but usually WRONG. FALSE 
    System.out.print(a1.equals(a2)); // RIGHT FALSE 
    
    String a3 = "something", a4 = "something";
    System.out.print(a3 == a4);      // Legal, but usually WRONG. TRUE 
    System.out.print(a3.equals(a4)); // RIGHT TRUE 
    
    String a5 = "somethingTTT"; 
    String a6 = "something;;;";
    a6 = a6.replace(';', 'T');
    System.out.print(a5 == a6);      // FALSE 
    System.out.print(a5.equals(a6)); // TRUE 
}

Jednak nie o tym jest wpis. Takie podchwytliwe pytanie mają sens. Mają one sprawdź twoją pasję do danego języka bądź znajomość określonych scenariuszy. Oczywiście żaden programista ,a zwłaszcza programista szukający pracy pierwszy raz  nie jest jak encyklopedia ,ale niestety czasami tak bywa. Dla obu stron nie ma idealnej metody bądź rozwiązania do uzyskania wspólnego celu.

Zanim zdobyłem pracy marzeń musiałem odbyć dużo rozmów kwalifikacyjnych. Na nie których z nich etykieta osób rekrutujących była pod dużym znakiem zapytania.

Bardzo rzadko to się zdarza ,ale czasem rekrutujący wie ,że odbywa daną rozmowę tylko po to by ją odbyć ,a  wtedy no cóż…dzieją się naprawdę dziwne rzeczy.

Najczęściej wtedy osoby rekrutujące chcą tak bardzo zabłysnąć swoją wiedzą ,że aż gadają czyste głupoty.  Zdarzyło mi się to tylko raz w trakcie rozmowy o pracy na stanowisko programisty C#.

Programista rekrutujący spytał mnie: czy klasa dziedziczą po klasie abstrakcyjnej musi koniecznie implementować metodę abstrakcyjną.

Moja odpowiedź była następująca: Nie ponieważ…

Niestety programista nie dał mi skończyć mojej odpowiedź i od razu uznał mnie za przygłupa i odpowiedział “pan się pomylił musi ona implementować metodę abstrakcyjną”.  Po czym odpowiedziałem ,ale przecież istnieje pewien wyjątek. A on na to nie ma żadnych wyjątków po czym przeszedł do następnego pytania. A ja trochę zwątpiłem swoją rację, ponieważ nie miałem przy sobie Visual Studio.

Jak myślicie kto ma racje?

No cóż zobaczmy jak sprawa przedstawia się w Visual Studio.

public abstract class Abstrakt
{
    public abstract void CheckThis();
}

public class Test : Abstrakt
{
    public override void CheckThis()
    {

    }
}

Na pierwszy rzut oka wydaj się ,że programista rekrutujący ma rację. Klasa dziedzicząca po klasie abstrakcyjnej musi dziedziczyć metodę abstrakcyjną. Klasa abstrakcyjna wtedy działa tak samo, jak Interfejs.

…istnieje jednak pewien wyjątek.

public abstract class Abstrakt
{
    public abstract void CheckThis();
}

public abstract class Test : Abstrakt
{

}

Jeśli klasa dziedzicząca po klasie abstrakcyjnej  jest także klasą abstrakcyjną to wtedy nie ma  wymogu implantacyjnego metody.

Moja strata była taka ,że za bardzo wtedy przeanalizowałem pytanie. Zupełnie jak za dawnych czasów gimnazjalnych  testów  gdzie zrozumienie formy pytania była ważniejsze niż twoja wiedza. W końcu w pytaniu nic nie było o tym, jaka to klasa ,a pytanie wyraźnie  wskazywało na wyrażenie “czy jest to koniecznie”.

Widać ,że przeżyłem ,za dużo rozmów kwalifikacyjnych i w każdym pytaniu zawsze próbuje dostrzec drugie dno.

Programista rekrutujący w jednej chwili stracił wszystko w moich oczach. Jakby tego było mało to był dopiero początek takich typowych odzywek. Jego język ciała wręcz świrował.

To właśnie nazywam nonszalanckim piekłem. Czasem się zastanawiam po co w ogóle odbywamy takie rozmowy kwalifikacyjne.  Chyba tylko po to by pokazać komuś na górze ,że wybraliśmy kogoś z dużego wora fikcyjnych opcji.

Zawsze rozmowy kwalifikacyjne można potraktować jako kolejny człon marketingu danej  firmy i zachować się przynajmniej przyzwoicie przy kandydacie nieważne jak głupi on by nie był.

Istnieje także inna historia ,ale nie przytrafiła mi się ona mnie.

Czy można stworzyć instancje klasy abstrakcyjnej?

Oczywiście ,że nie. Klasa abstrakcyjna może nie mieć ciał metod więc co ona mogła by robić bez ich definicji.

Mojemu znajomemu  jednak raz programista rekrutujący powiedział ,że jest to możliwe w ten sposób.

import java.io.Console;

abstract class Abstrakt {
    public abstract void checkThis();
}


public class Klaska  {

    public static void main(String[] args) {
        
        Abstrakt abstrakt = new Abstrakt() {

            @Override
            public void checkThis() {
                      System.out.print("Abstract");
                }
        };
        abstrakt.checkThis();
    }
}

Na pierwszy rzut oka WTF. Jak to jest możliwe czy naglę konie zaczną latać ,a jutro posmaruje herbatę szynką. Czy białej jest nadal białe, czy czarne? O_o

Nie ma co się martwić. Zasady się nie zmieniły nadal nie można stworzyć instancji klasy abstrakcyjnej.

Abstrakt abstrakt = new Abstrakt();

Powyższy kod pokazuje tworzenie  klasy anonimowej, która dziedziczy po klasie abstrakcyjnej.  Klasa anonimowa nie ma swojej nazwy więc wszystko jest tutaj okej.

Nie tworzymy  więc tutaj instancji klasy abstrakcyjnej tylko klasy anonimowej

Abstrakt abstrakt = new Abstrakt() {

};
abstrakt.checkThis();

Łatwo to udowodnić. Wystarczy skasować implementacje metody checkThis().

 

Musisz wewnątrz klasy anonimowej dodać implantację każdej metody abstrakcyjnej. Zupełnie tak jakby to była zwykła klasa.

Dziwna sprawa nieprawdaż. Zapewne rekrutujący był za bardzo zafascynowany klasami anonimowymi i sam dokładnie nie zrozumiał co tak naprawdę zrobił w taki kodzie. W paranoicznej wersji rzeczywistość programista rekrutujący chciał sprawdzić czy kandydat jest na tyle mądry ,że zobaczy trzecie dno danego pytania. W końcu programiści muszą myśleć na poziomie meta-meta.

Można też byłoby się kłócić ,że w pewnym sensie można mieć instancję klasy abstrakcyjnej (ale uwaga to gra słów).

import java.io.Console;

abstract class Abstrakt {
    public abstract void checkThis();
}

public class Klaska extends Abstrakt  {

    public static void main(String[] args) {
  
        Klaska klaska = new Klaska();
        System.out.print(klaska instanceof Abstrakt);   //TRUE
    }

        @Override 
        public void checkThis() {
            // TODO Auto-generated method stub
        }
}

Nie zmienia to faktu ,że definicja książkowa wyraźnie mówi o tym ,że klasa abstrakcyjna nie może tworzyć swojej  własnej instancji.

Nie ważna, jaką grę słów  byśmy  tutaj zastosowali klasa abstrakcyjna nie może tworzyć swojej własnej instancji.

Pamiętajcie na rozmowach kwalifikacyjnych nie dajcie się zaskoczyć. Trzymajcie się swojej własnej wiedzy grubo. Jeśli jej nie macie tą ją odświeżcie i uwierzcie ,że programista rekrutujący też jest człowiekiem i może się pomylić.

A ja się wam trafi jakiś nonszalancki typ, który nie lubi studentów to może jest to sygnał dla was ,że warunki pracy w tej firmie nie są najlepsze.