Erkundung der Fragen und Antworten aus einem Vorstellungsgespräch für eine Stelle als Java-Entwickler. Teil 3

Hallo! So wie es ohne spezielle Ausbildung unmöglich ist, das Fliegen eines Flugzeugs zu erlernen, kann man kein Java-Entwickler werden, ohne viele Stunden damit zu verbringen, sich die notwendigen theoretischen Grundlagen zu erarbeiten. Und genau daran werden wir heute arbeiten: Wir gehen weiterhin den Fragen nach, die in Vorstellungsgesprächen für Java-Entwickler auftauchen, und schauen uns natürlich die Antworten an. Hier sind der erste und zweite Teil dieser Übersicht. Es besteht kein Zweifel, dass Sie ohne all diese Fragen ein guter Java-Entwickler werden können. Wenn Sie jedoch alle Feinheiten von Java gut verstehen, sind Sie auf jeden Fall im Vorteil und werden in den Augen Ihres zukünftigen Arbeitgebers attraktiver aussehen.

20. Welche Elemente der Sprache ermöglichen die Kapselung?

Erinnern wir uns daran, dass es bei der Kapselung darum geht, die Implementierungsdetails einer Klasse zu verbergen. Mit anderen Worten: Wenn unsere Klasse verwendet wird, sind ihr Inneres und ihre interne Logik für Außenstehende nicht offensichtlich. Und welche Elemente der Sprache sind dafür verantwortlich? Zugriffsmodifikatoren natürlich! Alles, was wir verbergen müssen, markieren wir mit dem privaten Modifikator. Zum Beispiel die privaten Felder einer Klasse oder einige interne Methoden, die bei der Implementierung einiger interner Funktionen helfen. Und für alles, worauf wir externen Zugriff gewähren möchten, fügen wir den Modifikator für den öffentlichen Zugriff hinzu. Zum Beispiel eine Methode, die einige Funktionen implementiert (die intern möglicherweise viele private Methoden verwendet) oder natürlich Getter und Setter für den Zugriff auf die privaten Felder einer Klasse. Die Standard- und Protected- Modifikatoren, die flexibler eingesetzt werden können und den Zugriff auf bestimmte Klassenteile gezielt anpassen, haben wir noch nicht erwähnt .

21. Welche Elemente der Sprache ermöglichen die Vererbung?

Vererbung ist ein Mechanismus, der es Ihnen ermöglicht, Klassen basierend auf einer anderen Klasse zu erstellen. Java verfügt hierfür über das Schlüsselwort „extens“ . Angenommen, wir haben eine Cat- Klasse und möchten eine untergeordnete Lion- Klasse erstellen. 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 statischer Variablen. Ein weiteres Element der Sprache, das für die Vererbung verantwortlich ist, ist super . Es handelt sich um eine ähnliche Referenz wie diese . Das Schlüsselwort this bezieht sich auf das Objekt, in dem es referenziert wird. Das Schlüsselwort super bezieht sich auf das übergeordnete Objekt des aktuellen Objekts. Typischerweise wird Super verwendet:

1. Aufrufen des Konstruktors einer Superklasse. Beispielsweise verfügt die Cat- Klasse über eine interne Namensvariable , die im Konstruktor initialisiert werden muss. Im Lion- Klassenkonstruktor sieht das so aus:

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

2. Verweist auf die Felder und Methoden des übergeordneten Elements. In der Cat- Klasse haben wir beispielsweise ein initialisiertes Altersfeld :

   public class Cat {
      int age = 10;

Aber wir haben das gleiche initialisierte Feld in Lion :

public class Lion extends Cat {
   int age = 15;

Und wenn wir in einem Lion- Objekt auf die Altersvariable des übergeordneten Objekts verweisen möchten , müssen wir dies über super tun :

super.name

22. Welche Elemente der Sprache sind für Polymorphismus verantwortlich?

Polymorphismus ist die Fähigkeit eines Objekts mit einer Signatur, viele Formen (viele Implementierungen) anzunehmen. Wir können mit Sicherheit sagen, dass die Schlüsselwörter „implementiert “ und „extends“ von Java für den Polymorphismus verantwortlich sind. Wenn wir eine Schnittstelle haben, können wir mit „implements“ eine mögliche Implementierung bereitstellen, aber das muss nicht die einzige Implementierung sein, oder? Schauen wir uns noch einmal an, wie es aussieht, Geräte zu verwenden :

public class Cat implements Animal

Dann müssen wir in der Cat- Klasse alle abstrakten Methoden in der Animal- Schnittstelle implementieren. Auch Vererbung: In der untergeordneten Klasse können wir die vorhandene Implementierung einer Methode überschreiben. Das bedeutet, dass wir bei mehreren untergeordneten Klassen mehrere unterschiedliche Überschreibungen derselben Methode haben können. Oder eine Oberklasse kann abstrakt sein und eine bestimmte Methode haben, die in jeder ihrer untergeordneten Klassen auf besondere Weise implementiert werden muss. Mit anderen Worten: Diese Methode wird viele verschiedene Implementierungen haben. Dabei kann uns auch die Annotation @Override helfen. Es wird über den implementierten Methoden platziert und zeigt an, dass wir eine bestimmte Methode einer Superklasse oder Schnittstelle implementieren oder überschreiben möchten (sofern in der Superklasse bereits eine Implementierung vorhanden ist). Es ist optional und hilft, Fehler leichter zu erkennen. Mit dieser Annotation teilen Sie dem Compiler mit, dass Sie die Superklassen-/Schnittstellenmethode überschreiben/implementieren möchten. Der Compiler stellt dann sicher, dass Sie in der Methodensignatur keine Fehler machen.

23. Was ist SOLID? Geben Sie Beispiele an

SOLID ist ein Akronym für die fünf grundlegenden OOP-Designprinzipien von Robert Martin. S (Single-Responsibility-Prinzip) : besagt, dass eine Klasse nur einen Zweck/eine Verantwortung haben sollte. Mit anderen Worten: Sie sollten keine Klassen erstellen, die alles können. Wenn Sie dies tun, können Sie das Anti-Muster „Gottobjekt“ reproduzieren. Wenn Sie ein Cat- Objekt haben, sollte es nur über Methoden zur Interaktion mit seiner internen Funktionalität verfügen, aber keine Geschäftslogik enthalten, die nichts mit dieser Instanz zu tun hat. Zum Beispiel ein Mechanismus zum Speichern von Objekten dieses Typs. Diese Funktionalität (außerhalb der Entität eines Cat ) sollte auf andere Klassen oder Dienste verlagert werden, deren Aufgabe darin besteht, die Geschäftslogik für die entsprechenden Objekte bereitzustellen. O (Open-Closed-Prinzip) : Dieses Prinzip wird wie folgt beschrieben: Software-Entitäten (Klassen, Module, Funktionen usw.) sollten für Erweiterungen offen, für Änderungen jedoch geschlossen sein. Angenommen, wir benötigen eine Funktionalität, die der Funktionalität unserer vorhandenen Cat- Klasse ähnelt, sich jedoch geringfügig von dieser unterscheidet. Anstatt die Funktionalität der Cat- Klasse zu ändern und dadurch den Code überall dort zu zerstören, wo er bereits verwendet wird, können wir Vererbung oder Komposition verwenden . Damit erreichen wir unser Ziel, die Funktionalität der Cat- Klasse zu modifizieren, und zwar ohne die Klasse selbst zu ändern und ohne etwas kaputt zu machen. L (Liskov-Substitutionsprinzip) : Dies ist das Substitutionsprinzip von Barbara Liskov. Das Prinzip besagt, dass eine Funktion, die einen Basistyp annimmt, in der Lage sein sollte, Untertypen dieses Basistyps zu verwenden, ohne zu wissen, was passiert. Beispielsweise sollte unsere Cat- Klasse durch jeden ihrer Nachkommen, beispielsweise Lion , ersetzbar sein, ohne ihr Verhalten grundlegend zu ändern. Die allgemeine Logik (das Verhalten) bleibt gleich, aber die Implementierungsdetails spezifischer Funktionen ändern sich. I (Interface-Segregation-Prinzip) : Dieses Prinzip besagt, dass es besser ist, viele spezialisierte (eng fokussierte) Schnittstellen zu haben als eine universelle. Angenommen, ein Entwickler implementiert eine Schnittstelle. Sie benötigen nur eine ihrer Methoden, aber die Schnittstelle verfügt über neun weitere Methoden, die sich nicht auf die Logik der erforderlichen Methode beziehen. In diesem Fall muss der Entwickler zehn Schnittstellenmethoden implementieren, von denen neun für ihn überflüssig sind! Stattdessen ist es besser, zehn verschiedene Schnittstellen zu erstellen, die Sie nach Bedarf implementieren können. Nun, wenn nicht zehn, dann mehrere, jede mit Methoden, die eng mit dem einzelnen Zweck der Schnittstelle verbunden sind. D (Abhängigkeitsinversionsprinzip): Das Prinzip besagt, dass Module höherer Ebene nicht von Modulen niedrigerer Ebene abhängig sein sollten. In diesem Prinzip heißt es auch: „Abstraktion sollte nicht von Details abhängen. Details sollten von Abstraktionen abhängen.“ Wir müssen unsere Logik aufbauen, indem wir auf Schnittstellen verweisen und konkrete Objekte von Klassen weitergeben, die die erforderliche Schnittstelle implementieren. Angenommen, wir haben eine Cat- Schnittstelle und einige Implementierungen, beispielsweise Lion und HouseCat . Wir bauen unsere Logik speziell für die Interaktion mit der Cat- Schnittstelle auf. Wir ersetzen dann nur die Schnittstelle durch eine bestimmte Implementierung ( Lion oder HouseCat ), nicht jedoch umgekehrt.

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

Wir erinnern uns, dass Java eine OOP-Sprache ist. Das heißt, Java-Programme werden auf der Grundlage der Interaktionen zwischen Objekten erstellt. Ein Programm ist wie ein Ameisenhaufen, in dem jede Ameise ein Objekt ist. Objekte sind Datensammlungen, die verschiedene Methoden (Funktionen) zur Interaktion mit diesen internen Daten umfassen. Klassen sind Anweisungen oder Vorlagen zum Erstellen von Objekten. Das bedeutet, dass wir viele Objekte nach denselben Anweisungen erstellen, aber mit unterschiedlichen (oder denselben) Daten füllen können. Anhand eines Beispiels aus dem wirklichen Leben können wir sagen, dass eine Klasse der Bauplan eines Gebäudes ist und ein Objekt ein Gebäude, das speziell nach dem Bauplan gebaut wurde. Schnittstellen ähneln Klassen, wir können sie jedoch nicht zum Erstellen von Objekten verwenden. Ihr Zweck besteht darin, Java Abstraktion hinzuzufügen. Genauer gesagt erhöhen sie die Flexibilität der Beziehung zwischen Klassen und Objekten. Mit Flexibilität meinen wir den zuvor beschriebenen Polymorphismus und die Abstraktion, die viele Möglichkeiten für den Aufbau der internen Architektur einer Anwendung schaffen.

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

Ein POJO (Plain Old Java Object) ist ein einfaches Klassenobjekt, das nicht von einer bestimmten Klasse erbt 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 diese Klassen keine anderen Klassen (außer POJO- Klassen im selben Paket), implementieren keine Schnittstellen (manchmal wird eine Ausnahme für Markierungsschnittstellen aus der Standardbibliothek wie Serializable oder Cloneable gemacht ) und verwenden keine Anmerkungen und sind nicht auf Bibliotheken Dritter angewiesen. Beachten Sie, dass ein POJO über Methoden verfügen kann, die Geschäftslogik und Konstruktoren jeglicher Art enthalten. Wenn wir Annotationen zulassen, die die Semantik der Klasse nicht ändern (d. h. Annotationen, deren Fehlen den Zweck oder die Logik des Objekts nicht ändert), können POJOs auch aus XML oder JSON deserialisierte JPA- Entitäten und DTO -Objekte enthalten , deren Regeln gelten in Anmerkungen angegeben. Bei POJO- Klassen sollten Sie außerdem bedenken, dass es sinnvoll ist, ihre Equals- und HashCode- Methoden zu überschreiben, da sie dadurch ihre Rolle besser erfüllen können. Beispiel einer 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?

Eine Klasse kann folgende Elemente enthalten:

• Instanzfelder;
• statische Felder;
• ein Initialisierungsblock;
• ein statischer Initialisierungsblock;
• Konstruktoren (ein leerer Konstruktor wird standardmäßig immer deklariert);
• Methoden;
• statische Methoden;
• verschiedene Anmerkungen (die auf die Klasse selbst oder ihre Bestandteile angewendet werden können);
• Generika ;
• Vererbung anderer Klassen ( extends ) oder Implementierungen von Schnittstellen ( implements ).

27. Erzählen Sie uns etwas über die Vererbung in Java. Was sind die Besonderheiten des Super-Keywords?

Oben habe ich bereits über Vererbung und das Super- Schlüsselwort in Java gesprochen. Ich werde noch ein paar wichtige Punkte erwähnen:

1. Wir können nur eine einzelne Klasse erben: In Java gibt es keine Mehrfachvererbung. Mit dem Aufkommen von Standardmethoden in Java 8 wird diese Aussage sehr umstritten sein.
2. Private Methoden und Felder werden ebenfalls vererbt. Von der untergeordneten Klasse aus kann einfach nicht auf sie zugegriffen werden (wenn wir jedoch beispielsweise ein privates Feld und öffentliche oder geschützte Getter und Setter haben, können wir sie verwenden, um auf das Feld zuzugreifen).
3. Abschlussklassen können nicht vererbt werden.
4. Final -Methoden können nicht überschrieben werden (aber sie können vererbt und überladen werden).
5. Statische Methoden und Variablen werden nicht vererbt (da sie an Klassen und nicht an Objekte angehängt sind).
6. Beim Erben abstrakter Klassen müssen deren abstrakte Methoden implementiert werden, oder die untergeordnete 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 steht jedoch nicht über ihnen).
8. Sie können den Zugriffsmodifikator auf überschriebene Methoden in der untergeordneten Klasse erweitern: private -> default -> protected -> public .
Methoden, die in der untergeordneten Klasse überschrieben werden, können engere Ausnahmen auslösen, zum Beispiel: Exception -> IOException -> FileNotFoundException.

28. Was sind Methodensignaturen? Geben Sie Beispiele für korrekte und falsche Signaturen an

Eine Methodensignatur besteht aus dem Namen der Methode und den Typen der Eingabeparameter (die Reihenfolge der Parameter ist wichtig). Die Methodensignatur enthält weder den Rückgabewert noch die Ausnahmen, die die Methode auslöst. Beispiel einer korrekten Signatur:

doSomething(int, double, double)

Beispiel einer falschen 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!