Analyse von Fragen und Antworten aus Interviews für Java-Entwickler. Teil 3

Hallo! So wie es unmöglich ist, ohne spezielle Ausbildung das Fliegen eines Flugzeugs zu erlernen, ist es auch unmöglich, Java-Entwickler zu werden, ohne lange Stunden damit zu verbringen, die notwendigen theoretischen Grundlagen zu erlernen. Heute werden wir genau daran arbeiten: Wir werden weiterhin über 250 Interviewfragen für Java-Entwickler analysieren und dementsprechend Antworten darauf geben. Hier sind der erste und zweite Teil der Analyse. Ja, natürlich können Sie ohne all diese Fragen ein guter Java-Entwickler werden. Wenn Sie jedoch die Besonderheiten der Java-Sprache gut verstehen, verschaffen Sie sich einen Vorteil und machen Sie in den Augen Ihres zukünftigen Arbeitgebers zu einem attraktiveren Kandidaten.

20. Welche Sprachelemente sind für die Kapselung verantwortlich?

Wie wir uns erinnern, verbirgt die Kapselung die Implementierungsdetails einer Klasse. Das heißt, wenn unsere Klasse extern verwendet wird, sind der interne Inhalt und die interne Logik nicht offensichtlich. Und welche Elemente der Sprache sind dafür verantwortlich? Natürlich Zugriffsmodifikatoren ! Wir markieren mit dem privaten Modifikator , was wir verbergen müssen . Zum Beispiel private Felder einer Klasse oder einige interne Methoden, die bei der Implementierung bestimmter interner Funktionen helfen. Und zu dem, worauf wir externen Zugriff gewähren möchten, fügen wir den Modifikator für den öffentlichen Zugriff hinzu . Zum Beispiel eine Methode, die für die Bereitstellung einiger Funktionen verantwortlich ist (in der viele private Methoden verwendet werden können) oder dieselben Getter und Setter für den Zugriff auf private Felder einer Klasse. Oh, und wir haben auch die Standard- und geschützten Modifikatoren , die für eine flexiblere und spezifischere Konfiguration des Zugriffs auf ausgewählte Teile der Klasse verwendet werden können.

21. Welche Sprachelemente sind für die Vererbung verantwortlich?

Vererbung ist ein Mechanismus, der es Ihnen ermöglicht, Klassen basierend auf einer anderen Klasse zu erstellen. In Java wird zu diesem Zweck das Schlüsselwort „extends“ verwendet . Zum Beispiel haben wir eine bestimmte Klasse Cat und möchten ihren Nachfolger erstellen – Lion . Im Code sieht es etwa so aus:

public class Lion extends Cat

Und das bedeutet, dass die Lion- Klasse alle Methoden und Variablen der Cat- Klasse erbt , mit Ausnahme der statischen. Zu den für die Vererbung verantwortlichen Sprachelementen gehört auch super . Dies ist eine Referenz ähnlich wie this , aber während sich this auf das Objekt bezieht, für das es aufgerufen wurde, bezieht sich super auf das aktuelle übergeordnete Objekt. Typischerweise wird Super verwendet:

1. So rufen Sie einen Superklassenkonstruktor auf: Beispielsweise verfügt die Cat- Klasse über einen internen Variablennamen , der im Konstruktor initialisiert werden muss. Im Lion- Klassenkonstruktor würde es so aussehen:

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

2. So greifen Sie auf übergeordnete Felder und Methoden zu: In der Cat- Klasse haben wir beispielsweise ein initialisiertes Altersfeld :

   public class Cat {
      int age = 10;

Gleichzeitig haben wir in Lion das gleiche initialisierte Feld :

public class Lion extends Cat {
   int age = 15;

Und wenn wir vom Lion- Objekt aus auf die Altersvariable des übergeordneten Objekts zugreifen möchten , müssen wir dies über super tun :

super.name

22. Welche Sprachelemente sind für Polymorphismus verantwortlich?

Polymorphismus ist die Fähigkeit eines Objekts einer Signatur, viele Formen (mehrere Implementierungen) anzunehmen. Wir können mit Sicherheit sagen, dass in Java die Schlüsselwörter „implements“ und „extens“ für den Polymorphismus verantwortlich sind . implementiert – wenn wir unsere Schnittstelle erstellen, implementieren wir eine ihrer möglichen Formen in einer Klasse, aber es ist nicht die einzige Form, oder? Erinnern wir uns daran, wie die Implementierung von Geräten aussieht :

public class Cat implements Animal

Und in der Cat- Klasse müssen wir alle abstrakten Methoden implementieren, die in der Animal- Schnittstelle vorgestellt werden . Das Gleiche gilt für die Vererbung: In einer Nachkommenklasse können wir eine bereits vorhandene Implementierung einer Methode überschreiben. Zum Beispiel: mehrere Nachkommen -> mehrere verschiedene Überschreibungen derselben Methode. Nun, entweder war die Oberklasse abstrakt und sie verfügt über eine bestimmte Methode, die für jeden ihrer Nachkommen auf besondere Weise implementiert werden muss. Das heißt, wir können sagen, dass die Methode viele Formen annehmen wird. Dabei kann uns auch die Annotation @Override helfen , die über den implementierten Methoden platziert wird und angibt, dass wir die eine oder andere Methode der Superklasse oder Schnittstelle implementieren oder überschreiben möchten (falls die Implementierung bereits in der Superklasse vorhanden ist). Sie ist optional und dient der einfacheren Fehlererkennung. Mit dieser Annotation teilen Sie dem Compiler mit, dass Sie eine Superklassen-/Schnittstellenmethode überschreiben/implementieren möchten, und stellen sicher, dass Sie keine Fehler in der Methodensignatur machen.

23. Was ist SOLID? Nenne Beispiele

SOLID ist eine Abkürzung für die fünf grundlegenden Designprinzipien für OOP, die von Robert Martin geprägt wurden. S – Prinzip der Einzelverantwortung – das Prinzip der Einzelverantwortung, das besagt, dass eine Klasse nur ein Ziel und einen einzigen Zweck haben sollte. Das heißt, Sie sollten keine Klassen erstellen, die alles tun. In diesem Fall können Sie das Antimuster „Göttliches Objekt“ reproduzieren. Wenn Sie ein Cat- Objekt haben , sollte es Methoden enthalten, die nur mit seiner internen Funktionalität interagieren, und keine Geschäftslogik, die für diese Instanz nicht relevant ist. Zum Beispiel eine Art Speicherung von Objekten dieser Art irgendwo. Diese externe Funktionalität (relativ zu Cat ) muss auf andere Klassen übertragen werden, einige Dienste, deren Aufgabe es ist, Geschäftslogik für Objekte dieses Typs bereitzustellen. O – Open-Closed-Prinzip – Prinzip der Offenheit/Geschlossenheit. Dies bedeutet, dass Softwareeinheiten (Klassen, Schnittstellen) für Erweiterungen offen, für Änderungen jedoch geschlossen sein sollten. Beispielsweise benötigten wir eine Funktionalität, die der Funktionalität der bereits vorhandenen Cat- Klasse ähnelt , jedoch etwas anders ist. Anstatt die Funktionalität der Cat- Klasse zu ändern und die Stellen aufzubrechen, an denen sie bereits verwendet wird, verwenden wir Vererbung oder Komposition . Dadurch haben wir unser Ziel mit der geänderten Funktionalität der Cat- Klasse erreicht , aber gleichzeitig haben wir sie nicht verändert oder kaputt gemacht. L – Liskov-Substitutionsprinzip – Barbara Liskovs Substitutionsprinzip. Das Prinzip besagt, dass eine Funktion, die einen Basistyp verwendet, in der Lage sein sollte, Untertypen des Basistyps zu verwenden, ohne es zu wissen. Beispielsweise sollte unsere Cat- Klasse mit jedem ihrer Nachkommen, beispielsweise Lion , austauschbar sein, ohne das Verhalten grundlegend zu ändern. Die allgemeine Logik (das Verhalten) bleibt gleich, aber die Details der Implementierung dieser oder jener Funktionalität ändern sich. I – Interface-Segregation-Prinzip – das Prinzip der Interface-Trennung. Dieses Prinzip besagt, dass es besser ist, viele spezialisierte (eng fokussierte) Schnittstellen zu haben als eine universelle. Beispielsweise implementiert ein Benutzer eine Schnittstelle, von der er nur diese Methode benötigt, diese Schnittstelle verfügt jedoch über neun weitere Methoden, die nichts mit der Logik der gewünschten Methode zu tun haben. In diesem Fall muss der Benutzer zehn Schnittstellenmethoden implementieren, von denen neun für ihn unnötig sind! Stattdessen ist es besser, zehn verschiedene Schnittstellen zu erstellen, die bei Bedarf implementiert werden können. Nun, oder nicht zehn, sondern mehrere, die über Methoden verfügen, die eng mit dem gemeinsamen Zweck der Schnittstelle verbunden sind. D – Abhängigkeitsinversionsprinzip— das Prinzip der Abhängigkeitsumkehr. Der Grundsatz besagt, dass Module auf höheren Ebenen nicht von Modulen auf niedrigeren Ebenen abhängen sollten. Dieses Prinzip wird auch als „Abstraktion sollte nicht von Details abhängen, Details sollten von der Abstraktion abhängen“ beschrieben. Das heißt, wir müssen unsere Logik aufbauen, indem wir auf Schnittstellen verweisen, und erst dann bestimmte Objekte an diese Funktionalität übergeben, deren Klassen die erforderliche Schnittstelle implementieren. Wenn wir beispielsweise über eine Cat- Schnittstelle und einige ihrer Implementierungen verfügen, beispielsweise Lion und HomeCat , bauen wir unsere Interaktionslogik speziell mit dem Cat- Schnittstellentyp auf und ersetzen sie erst dann durch eine bestimmte Implementierung von Lion oder HomeCat , nicht jedoch umgekehrt.

24. Was ist eine Klasse, ein Objekt, eine Schnittstelle?

Wie wir uns erinnern, ist Java eine OOP-Sprache. Das heißt, Java-Programme basieren auf der Interaktion zwischen Objekten. Es stellt sich heraus, dass das Programm wie ein Ameisenhaufen ist, in dem jede Ameise ein Objekt ist. Bei Objekten handelt es sich um gruppierte Daten, die verschiedene Methoden (Funktionen) zur Interaktion mit diesen internen Daten enthalten. Und Klassen sind Anweisungen, Vorlagen zum Erstellen von Objekten. Das heißt, es können viele Objekte vorhanden sein, die nach derselben Anweisung erstellt und mit unterschiedlichen oder identischen Datenwerten gefüllt werden. Als Beispiel aus dem Leben können wir sagen, dass eine Klasse eine Zeichnung eines Gebäudes ist und ein Objekt ein speziell auf dieser Zeichnung erstelltes Gebäude. Schnittstellen sind Analoga von Klassen mit dem Unterschied, dass mit ihnen keine Objekte erstellt werden können. Ihr Ziel ist es, Java ein Element der Abstraktion hinzuzufügen. Genauer gesagt, um die Beziehungen zwischen Klassen und Objekten flexibler zu gestalten. Mit Flexibilität meinen wir den zuvor beschriebenen Polymorphismus und die Abstraktion, die wiederum viele Möglichkeiten für den Aufbau der internen Architektur der Anwendung eröffnen.

25. Was ist eine POJO-Klasse? Geben Sie ein Beispiel für eine solche Klasse

POJO – Plain Old Java Object – ein gutes altes Java-Objekt: ein einfaches Objekt einer Klasse, das nicht von einer bestimmten Klasse geerbt wird und keine Serviceschnittstellen implementiert, die über die für das Geschäftsmodell erforderlichen hinausgehen. Mit anderen Worten : Eine POJO- Klasse ist lediglich eine Klasse ohne besondere Anforderungen. Die einzige Voraussetzung ist der Verzicht auf diversen Schnickschnack, der an einen bestimmten Rahmen gebunden ist. In der Regel erben solche Klassen nicht von anderen Klassen (mit Ausnahme von POJO- Klassen aus demselben Paket), implementieren keine Schnittstellen – manchmal wird eine Ausnahme für Markierungsschnittstellen aus der Standardbibliothek wie Serializable oder Cloneable gemacht – verwenden keine Annotationen und sind nicht auf Bibliotheken von Drittanbietern angewiesen. Ich stelle jedoch fest, dass POJOs Methoden mit Geschäftslogik und Konstruktoren jeglicher Art haben können. Wenn Sie Anmerkungen zulassen, die keine Änderungen an der Semantik der Klasse vornehmen (ohne die sich der Zweck des Objekts und die Logik seiner Operation nicht ändern), können POJOs auch JPA- Entitätsentitäten und aus XML oder JSON deserialisierte DTO -Objekte umfassen . Die Regeln hierfür sind in den Anmerkungen angegeben. Es ist außerdem ratsam, equal und hashCode für POJO- Klassen zu überschreiben , da dies ihnen helfen kann, ihre Rolle besser zu erfüllen. Beispiel- POJO- Klasse:

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. Welche Elemente kann eine Klasse enthalten?

Die Klasse kann folgende Elemente enthalten:

• Klassenfelder;
• statische Klassenfelder;
• Initialisierungsblock;
• statischer Initialisierungsblock;
• Konstruktoren (leer ist standardmäßig immer definiert);
• Methoden;
• statische Methoden;
• verschiedene Anmerkungen (die über der Klasse selbst oder ihren Komponenten hängen können);
• Generika ;
• Vererbung von anderen Klassen ( extends ) oder Implementierung von Schnittstellen ( implementiert ).

27. Erklären Sie die Vererbung in Java. Welche Vorteile bietet die Verwendung des Super-Keywords?

Oben habe ich bereits über Vererbung und das Super- Schlüsselwort in Java gesprochen. Lassen Sie mich noch einige wichtige Punkte erwähnen:

1. Es ist möglich, nur eine Klasse zu erben: In Java gibt es keine Mehrfachvererbung (aber mit dem Aufkommen von Standardmethoden in Java 8 wird diese Aussage sehr umstritten sein).
2. Private Methoden und Felder werden ebenfalls vererbt, sie haben vom Erben lediglich keinen Zugriff darauf (wenn wir jedoch beispielsweise ein privates Feld haben und es dafür öffentliche oder geschützte Getter und Setter gibt, kann mit dem Feld gearbeitet werden durch sie).
3. Abschlussklassen werden nicht vererbt.
4. Final -Methoden werden nicht überschrieben (sie können jedoch vererbt und überladen werden).
5. Statische Methoden und Variablen werden nicht vererbt (da sie nicht an Objekte, sondern an Klassen gebunden sind).
6. Beim Erben von abstrakten Klassen ist die Implementierung ihrer abstrakten Methoden erforderlich, oder die aktuelle Klasse muss ebenfalls als abstrakt deklariert werden.
7. Wenn es in der übergeordneten Klasse nicht standardmäßige Konstruktoren gibt, müssen diese in der untergeordneten Klasse überschrieben werden ( @Override wird jedoch nicht über sie geschrieben).
8. Überschriebene Methoden im Nachkommen können mit einem Zugriffsmodifikator erweitert werden: private -> default -> protected -> public .
9. Überschriebene Methoden im Nachkommen können die geschriebenen Ausnahmen eingrenzen, zum Beispiel: Exception -> IOException -> FileNotFoundException.

28. Was ist eine Methodensignatur? Nennen Sie Beispiele für richtige und falsche Signaturen

Die Signatur einer Methode besteht aus dem Namen der Methode sowie den Typen der eingehenden Parameter (und die Reihenfolge der Parameter ist wichtig). Die Methodensignatur enthält weder den Rückgabewert noch die von ihr ausgelösten Ausnahmen. Beispiel einer korrekten Signatur:

doSomething(int, double, double)

Ein Beispiel für eine falsche Signatur:

void doSomething(int firstArg, int secondArg) throws Exception

Die Methodensignatur wird zusammen mit dem Rückgabetyp und der Liste der ausgelösten Ausnahmen als Methodenvertrag bezeichnet . Das ist alles für heute. Bis später!