Analiza pytań i odpowiedzi z rozmów kwalifikacyjnych dla programisty Java. Część 3

Cześć! Tak jak nie da się nauczyć latać samolotem bez specjalnego przeszkolenia, tak nie da się zostać programistą Java bez spędzenia długich godzin na studiowaniu niezbędnych podstaw teoretycznych. Dzisiaj będziemy pracować dokładnie nad tym: będziemy nadal analizować ponad 250 pytań do rozmów kwalifikacyjnych dla programistów Java i odpowiednio na nie odpowiedzi. Oto pierwsza i druga część analizy. Tak, oczywiście, możesz zostać dobrym programistą Java bez tych wszystkich pytań. Jeśli jednak dobrze rozumiesz tajniki języka Java, da ci to przewagę i sprawi, że będziesz bardziej pożądanym kandydatem w oczach przyszłego pracodawcy.

20. Jakie elementy języka odpowiadają za enkapsulację?

Jak pamiętamy, enkapsulacja ukrywa szczegóły implementacji klasy. Oznacza to, że gdy nasza klasa jest używana zewnętrznie, wewnętrzna zawartość i logika nie są oczywiste. A jakie elementy języka za to odpowiadają? Naturalnie modyfikatory dostępu ! Za pomocą modyfikatora private zaznaczamy to, co chcemy ukryć . Na przykład prywatne pola klasy lub niektóre metody wewnętrzne, które pomagają wdrożyć określone funkcje wewnętrzne. A do tego, do czego chcemy zapewnić dostęp zewnętrzny, dodajemy modyfikator dostępu publicznego . Na przykład metoda odpowiedzialna za zapewnienie pewnej funkcjonalności (w ramach której można zastosować wiele metod prywatnych) lub te same metody pobierające i ustawiające umożliwiające dostęp do prywatnych pól klasy. Aha, mamy też modyfikatory default i chroniony , które można wykorzystać do bardziej elastycznej i specyficznej konfiguracji dostępu do wybranych części klasy.

21. Które elementy języka odpowiadają za dziedziczenie?

Dziedziczenie to mechanizm pozwalający na tworzenie klas w oparciu o inną klasę. W Javie do tego celu używa się słowa kluczowego Extends . Przykładowo mamy pewną klasę Cat i chcemy stworzyć jej następcę – Lion . W kodzie będzie to wyglądać mniej więcej tak:

public class Lion extends Cat

A to oznacza, że ​​klasa Lion dziedziczy wszystkie metody i zmienne klasy Cat , z wyjątkiem statycznych. Ponadto elementy języka odpowiedzialne za dziedziczenie obejmują super . Jest to odwołanie podobne do this , ale chociaż this odnosi się do obiektu, na którym zostało wywołane, super odnosi się do bieżącego obiektu nadrzędnego. Zwykle używa się super :

1. Aby wywołać konstruktor nadklasy: Na przykład klasa Cat ma wewnętrzną nazwę zmiennej , którą należy zainicjować w konstruktorze. W konstruktorze klasy Lion wyglądałoby to tak:

   public Lion(final String name) {
      super(name);
   }

2. Aby uzyskać dostęp do pól i metod nadrzędnych: na przykład w klasie Kot mamy zainicjowane pole wieku :

   public class Cat {
      int age = 10;

Jednocześnie mamy to samo zainicjowane pole w Lionie :

public class Lion extends Cat {
   int age = 15;

A jeśli chcemy uzyskać dostęp do zmiennej wieku obiektu nadrzędnego z obiektu Lion , musimy to zrobić za pomocą super :

super.name

22. Które elementy języka odpowiadają za polimorfizm?

Polimorfizm to zdolność obiektu jednego podpisu do przybierania wielu form (wiele implementacji). Można śmiało powiedzieć, że w Javie za polimorfizm odpowiedzialne są słowa kluczowe implements i Extends . implements - tworząc nasz interfejs, implementujemy w jakiejś klasie jedną z jego możliwych form, ale nie jest to jedyna forma, prawda? Przypomnijmy jak wygląda wdrażanie narzędzi :

public class Cat implements Animal

Natomiast w klasie Cat musimy zaimplementować wszystkie abstrakcyjne metody prezentowane w interfejsie Animal . To samo tyczy się dziedziczenia: w klasie potomnej możemy nadpisać istniejącą już implementację metody. Na przykład: kilku potomków -> kilka różnych przesłonięć tej samej metody. Cóż, albo nadklasa była abstrakcyjna i posiada pewną metodę, którą należy zaimplementować w specjalny sposób dla każdego ze swoich potomków. Oznacza to, że możemy powiedzieć, że metoda ta będzie przybierać różne formy. Pomoże nam w tym także adnotacja @Override , która jest umieszczona nad zaimplementowanymi metodami i wskazuje, że chcemy zaimplementować lub zastąpić (jeśli implementacja już istnieje w nadklasie) tę lub inną metodę nadklasy lub interfejsu. Jest to opcjonalne i służy do ułatwienia wykrywania błędów. Za pomocą tej adnotacji wskazujesz kompilatorowi, że chcesz zastąpić/zaimplementować metodę nadklasy/interfejsu, co zapewni, że nie popełnisz błędów w sygnaturze metody.

23. Co to jest SOLIDNE? Daj przykłady

SOLID to akronim pięciu podstawowych zasad projektowania dla OOP, wymyślonych przez Roberta Martina. S - Zasada pojedynczej odpowiedzialności - zasada pojedynczej odpowiedzialności, która stwierdza, że ​​klasa powinna mieć tylko jeden cel i jeden cel. Oznacza to, że nie powinieneś tworzyć klas, które robią wszystko. W tym przypadku możesz odtworzyć antywzorzec „Boskiego obiektu”. Jeśli masz obiekt Cat , powinien on zawierać metody, które wchodzą w interakcję tylko z jego wewnętrzną funkcjonalnością, a nie logiką biznesową, która nie jest istotna dla tej instancji. Na przykład jakieś zapisanie gdzieś tego typu obiektów. Tę zewnętrzną funkcjonalność (w stosunku do Cat ) należy przenieść do innych klas, niektórych usług, których zadaniem jest zapewnienie logiki biznesowej dla obiektów tego typu. O - Zasada otwarte-zamknięte - zasada otwartości/zamkniętości. Oznacza to, że jednostki oprogramowania (klasy, interfejsy) powinny być otwarte na rozbudowę, ale zamknięte na modyfikację. Przykładowo potrzebowaliśmy funkcjonalności podobnej do funkcjonalności już istniejącej klasy Cat , jednak nieco innej. Zamiast zmieniać funkcjonalność klasy Cat , rozbijając miejsca, w których jest ona już używana, stosujemy dziedziczenie lub kompozycję . W rezultacie osiągnęliśmy nasz cel w postaci zmodyfikowanej funkcjonalności klasy Cat , ale jednocześnie niczego nie zmienialiśmy ani nie psuliśmy. L – Zasada substytucji Liskowa – zasada substytucji Barbary Liskov. Zasada mówi, że funkcja korzystająca z typu podstawowego powinna mieć możliwość korzystania z podtypów typu podstawowego, nie wiedząc o tym. Na przykład nasza klasa Cat powinna być wymienna z dowolnym jej potomkiem, powiedzmy Lion , bez zasadniczej zmiany zachowania. Ogólna logika (zachowanie) pozostaje taka sama, ale zmieniają się szczegóły wdrożenia tej lub innej funkcjonalności. I - Zasada segregacji interfejsów - zasada separacji interfejsów. Zasada ta głosi, że lepiej mieć wiele wyspecjalizowanych (wąsko ukierunkowanych) interfejsów niż jeden uniwersalny. Na przykład użytkownik implementuje jakiś interfejs, z którego potrzebuje tylko tej metody, ale ten interfejs ma jeszcze dziewięć metod, które nie mają nic wspólnego z logiką pożądanej metody. W takim przypadku użytkownik będzie musiał zaimplementować dziesięć metod interfejsu, z czego dziewięć jest dla niego zbędnych! Zamiast tego lepiej stworzyć dziesięć różnych interfejsów, które można zaimplementować w razie potrzeby. No może nie dziesięć, ale kilka, które będą miały metody ściśle powiązane ze wspólnym celem interfejsu. D – Zasada inwersji zależności— zasada inwersji zależności. Zasada stanowi, że moduły na wyższych poziomach nie powinny zależeć od modułów na niższych poziomach. Zasada ta jest również opisana jako „abstrakcja nie powinna zależeć od szczegółów, szczegóły powinny zależeć od abstrakcji”. Oznacza to, że musimy budować naszą logikę odwołując się do interfejsów, a dopiero potem przekazywać do tej funkcjonalności określone obiekty, których klasy implementują wymagany interfejs. Na przykład, jeśli mamy interfejs Cat i niektóre jego implementacje, powiedzmy Lion i HomeCat , budujemy naszą logikę interakcji specjalnie z typem interfejsu Cat , a dopiero potem zastępujemy konkretną implementację Lion lub HomeCat , ale nie odwrotnie.

24. Co to jest klasa, obiekt, interfejs?

Jak pamiętamy, Java jest językiem OOP. Oznacza to, że programy Java są zbudowane na interakcji między obiektami. Okazuje się, że program jest jak mrowisko, gdzie każda mrówka jest obiektem. Obiekty to pogrupowane dane zawierające różne metody (funkcje) umożliwiające interakcję z danymi wewnętrznymi. A zajęcia to instrukcje, szablony do tworzenia obiektów. Oznacza to, że może istnieć wiele obiektów zbudowanych według tej samej instrukcji, wypełnionych różnymi lub identycznymi wartościami danych. Aby dać przykład z życia, możemy powiedzieć, że klasa to rysunek budynku, a obiekt to specjalnie utworzony budynek na podstawie tego rysunku. Interfejsy są odpowiednikami klas, z tą różnicą, że nie można przy ich pomocy tworzyć obiektów. Ich celem jest dodanie elementu abstrakcji do Javy. Dokładniej, aby dodać elastyczność w relacjach pomiędzy klasami i obiektami. Przez elastyczność rozumiemy opisany wcześniej polimorfizm i abstrakcję, które z kolei otwierają wiele możliwości budowania wewnętrznej architektury aplikacji.

25. Co to jest klasa POJO? Podaj przykład takiej klasy

POJO - Plain Old Java Object - stary, dobry obiekt Java: prosty obiekt klasy, który nie jest dziedziczony z żadnej konkretnej klasy i nie implementuje żadnych interfejsów usług poza tymi, które są potrzebne w modelu biznesowym. Innymi słowy , klasa POJO to po prostu klasa bez specjalnych wymagań. Jedynym wymaganiem jest brak różnych bajerów związanych z określonymi ramami. Z reguły takie klasy nie dziedziczą po innych klasach (poza klasami POJO z tego samego pakietu), nie implementują interfejsów - czasem robi się wyjątek dla interfejsów znaczników ze standardowej biblioteki takich jak Serializable czy Cloneable - nie używaj adnotacji i nie zależą od bibliotek stron trzecich. Zauważam jednak, że POJO mogą mieć metody z logiką biznesową i dowolnymi konstruktorami. Jeśli zezwolisz na adnotacje nie wprowadzające zmian w semantyce klasy (bez których cel obiektu i logika jego działania nie ulegnie zmianie), POJO mogą zawierać również encje JPA Entity i obiekty DTO deserializowane z XML lub JSON , zasady, których zasady są określone w adnotacjach. Wskazane jest również zastąpienie równości i hashCode dla klas POJO , ponieważ może to pomóc im lepiej spełniać swoją rolę. Przykładowa klasa POJO :

public class User {
   private Long id;
   private String firstName;
   private String lastName;
   private Long age;

   public User(final Long id, final String firstName, final String lastName, final long age) {
       this.id = id;
       this.firstName = firstName;
       this.lastName = lastName;
       this.age = age;
   }

   public Long getId() {
       return this.id;
   }

   public String getFirstName() {
       return this.firstName;
   }

   public String getLastName() {
       return this.lastName;
   }

   public Long getAge() {
       return this.age;
   }

   @Override
   public boolean equals(final Object o) {
       if (this == o) return true;
       if (o == null || this.getClass() != o.getClass()) return false;
       final User user = (User) o;
       return Objects.equals(this.id, user.id) &&
               Objects.equals(this.firstName, user.firstName) &&
               Objects.equals(this.lastName, user.lastName) &&
               Objects.equals(this.age, user.age);
   }

   @Override
   public int hashCode() {
       return Objects.hash(this.id, this.firstName, this.lastName, this.age);
   }
}

26. Jakie elementy może zawierać klasa?

Klasa może zawierać następujące elementy:

• pola klas;
• pola klas statycznych;
• blok inicjujący;
• statyczny blok inicjujący;
• konstruktory (domyślnie zawsze zdefiniowany jest pusty);
• metody;
• metody statyczne;
• różne adnotacje (które mogą wisieć nad samą klasą lub jej komponentami);
• leki generyczne ;
• dziedziczenie z innych klas ( ekstensje ) lub implementacja z interfejsów ( implementy ).

27. Wyjaśnij dziedziczenie w Javie. Jakie są korzyści ze stosowania słowa kluczowego super?

Powyżej mówiłem już o dziedziczeniu i słowie kluczowym super w Javie. Wspomnę jeszcze o kilku ważnych kwestiach:

1. Możliwe jest dziedziczenie tylko jednej klasy: w Javie nie ma dziedziczenia wielokrotnego (ale wraz z pojawieniem się metod domyślnych w Javie 8 stwierdzenie to stanie się bardzo kontrowersyjne).
2. Prywatne metody i pola również są dziedziczone, po prostu nie będą miały do ​​nich dostępu od spadkobiercy (ale jeśli na przykład mamy prywatne pole i istnieją dla niego publiczne lub chronione metody pobierające i ustawiające, z polem można pracować przez nich).
3. klasy końcowe nie są dziedziczone.
4. metody final nie są zastępowane (ale mogą być dziedziczone i przeciążane).
5. metody i zmienne statyczne nie są dziedziczone (ponieważ są powiązane nie z obiektami, ale z klasami).
6. Podczas dziedziczenia z klas abstrakcyjnych wymagana jest implementacja ich metod abstrakcyjnych lub bieżąca klasa również musi zostać zadeklarowana jako abstrakcyjna.
7. Jeśli w klasie nadrzędnej znajdują się konstruktory inne niż domyślne, należy je przesłonić w klasie potomnej (ale @Override nie jest nad nimi zapisywane).
8. Przesłonięte metody w potomku można rozszerzyć za pomocą modyfikatora dostępu: private -> default -> protected -> public .
9. Przesłonięte metody w potomku mogą zawęzić zapisywane wyjątki, na przykład: Wyjątek -> IOException -> FileNotFoundException.

28. Co to jest sygnatura metody? Podaj przykłady podpisów prawidłowych i błędnych

Sygnatura metody to nazwa metody oraz typy przychodzących parametrów (i kolejność parametrów ma znaczenie). Sygnatura metody nie zawiera wartości zwracanej ani zgłaszanych wyjątków. Przykład prawidłowego podpisu:

doSomething(int, double, double)

Przykład błędnego podpisu:

void doSomething(int firstArg, int secondArg) throws Exception

Sygnatura metody w połączeniu z typem zwracanym i listą zgłaszanych wyjątków nazywana jest kontraktem metody . To wszystko na dzisiaj. Do zobaczenia później!