Explorer les questions et réponses d'un entretien d'embauche pour un poste de développeur Java. Partie 3

Salut! Tout comme il est impossible d’apprendre à piloter un avion sans formation particulière, on ne peut pas devenir développeur Java sans passer de longues heures à étudier les bases théoriques nécessaires. Et c'est précisément sur cela que nous allons travailler aujourd'hui : nous continuerons à explorer les questions rencontrées lors des entretiens d'embauche pour les développeurs Java et, bien sûr, nous examinerons les réponses. Voici la première et la deuxième partie de cet aperçu. Il ne fait aucun doute que vous pouvez devenir un bon développeur Java sans toutes ces questions. Cela dit, si vous comprenez bien toutes les subtilités de Java, vous aurez certainement un avantage et paraîtrez plus attrayant aux yeux de votre futur employeur.

20. Quels éléments du langage permettent l'encapsulation ?

Rappelons que l'encapsulation consiste à masquer les détails d'implémentation d'une classe. En d’autres termes, lorsque notre classe est utilisée, ses entrailles et sa logique interne ne sont pas évidentes pour les étrangers. Et quels éléments du langage en sont responsables ? Des modificateurs d'accès , bien sûr ! Tout ce que nous devons cacher, nous le marquons avec le modificateur private . Par exemple, les champs privés d'une classe ou certaines méthodes internes permettant d'implémenter certaines fonctionnalités internes. Et pour tout ce à quoi nous souhaitons fournir un accès externe, nous ajoutons le modificateur d'accès public . Par exemple, une méthode qui implémente certaines fonctionnalités (qui peuvent utiliser en interne de nombreuses méthodes privées) ou, bien sûr, des getters et des setters pour accéder aux champs privés d'une classe. Nous n'avons pas encore mentionné les modificateurs par défaut et protégés , qui peuvent être utilisés de manière plus flexible et personnaliser spécifiquement l'accès à certaines parties de classe.

21. Quels éléments du langage permettent l'héritage ?

L'héritage est un mécanisme qui vous permet de créer des classes basées sur une autre classe. Java a le mot-clé extends pour cela. Par exemple, supposons que nous ayons une classe Cat et que nous souhaitions créer une classe enfant Lion . Dans le code, cela ressemblera à ceci :

public class Lion extends Cat

Et cela signifie que la classe Lion hérite de toutes les méthodes et variables de la classe Cat , à l'exception des variables statiques. Un autre élément du langage responsable de l'héritage est super . C'est une référence similaire à celle-ci . Le mot-clé this fait référence à l'objet dans lequel il est référencé. Le super mot-clé fait référence au parent de l'objet actuel. Généralement, super est utilisé :

1. Appeler le constructeur d’une superclasse. Par exemple, la classe Cat possède une variable de nom interne qui doit être initialisée dans le constructeur. Dans le constructeur de la classe Lion , cela ressemblera à ceci :

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

2. Pour faire référence aux champs et méthodes du parent. Par exemple, dans la classe Cat , nous avons un champ age initialisé :

   public class Cat {
      int age = 10;

Mais nous avons le même champ initialisé dans Lion :

public class Lion extends Cat {
   int age = 15;

Et si dans un objet Lion nous voulons faire référence à la variable age de l'objet parent, alors nous devons le faire via super :

super.name

22. Quels éléments du langage sont responsables du polymorphisme ?

Le polymorphisme est la capacité d'un objet avec une seule signature à prendre plusieurs formes (plusieurs implémentations). Nous pouvons affirmer avec certitude que les mots-clés Implements et Extends de Java sont responsables du polymorphisme. Lorsque nous avons une interface, Implements nous permet de fournir une implémentation possible, mais cela ne doit pas nécessairement être la seule implémentation, n'est-ce pas ? Revoyons à quoi ressemble l'utilisation d'impléments :

public class Cat implements Animal

Ensuite dans la classe Cat , nous devons implémenter toutes les méthodes abstraites dans l' interface Animal . L'héritage également : dans la classe enfant, nous pouvons remplacer l'implémentation existante d'une méthode. Cela signifie qu'avec plusieurs classes enfants, nous pouvons avoir plusieurs remplacements différents de la même méthode. Ou bien une superclasse peut être abstraite et avoir une certaine méthode qui doit être implémentée d'une manière particulière dans chacune de ses classes enfants. En d’autres termes, cette méthode aura de nombreuses implémentations différentes. L' annotation @Override peut également nous aider. Il est placé au-dessus des méthodes implémentées et indique que l'on souhaite implémenter ou remplacer (si une implémentation existe déjà dans la superclasse) une méthode particulière d'une superclasse ou d'une interface. Il est facultatif et permet de détecter plus facilement les erreurs. Vous utilisez cette annotation pour indiquer au compilateur que vous souhaitez remplacer/implémenter la méthode superclasse/interface. Le compilateur s'assurera alors que vous ne faites pas d'erreurs dans la signature de la méthode.

23. Qu'est-ce que SOLIDE ? Fournir des exemples

SOLID est l'acronyme des cinq principes de base de conception POO de Robert Martin. S (Principe de responsabilité unique) : stipule qu'une classe ne doit avoir qu'un seul objectif/responsabilité. En d’autres termes, il ne faut pas créer des classes qui font tout. Si vous le faites, vous risquez de reproduire l'anti-modèle « Objet Dieu ». Si vous disposez d'un objet Cat , il doit disposer de méthodes uniquement pour interagir avec ses fonctionnalités internes, mais il ne doit contenir aucune logique métier sans rapport avec cette instance. Par exemple, un mécanisme permettant de stocker des objets de ce type. Cette fonctionnalité (externe à l'entité d'un Cat ) doit être déplacée vers d'autres classes ou services, dont la tâche est de fournir la logique métier pour les objets correspondants. O (Principe Ouvert-Fermé) : Ce principe est décrit comme suit : les entités logicielles (classes, modules, fonctions, etc.) doivent être ouvertes à l'extension mais fermées à la modification. Par exemple, supposons que nous ayons besoin de fonctionnalités similaires mais légèrement différentes de celles de notre classe Cat existante . Au lieu de modifier les fonctionnalités de la classe Cat et ainsi de casser le code partout où il est déjà utilisé, nous pouvons utiliser l'héritage ou la composition . Ainsi, nous atteignons notre objectif de modifier les fonctionnalités de la classe Cat , et nous le faisons sans changer la classe elle-même et sans rien casser. L (Liskov Substitution Principe) : c'est le principe de substitution de Barbara Liskov. Le principe dit qu'une fonction qui prend un type de base devrait pouvoir utiliser des sous-types de ce type de base sans savoir ce qui se passe. Par exemple, notre classe Cat devrait être remplaçable par n'importe lequel de ses descendants, disons Lion , sans changer fondamentalement son comportement. La logique générale (comportement) reste la même, mais les détails d'implémentation de fonctionnalités spécifiques changent. I (Principe de ségrégation des interfaces) : ce principe stipule qu'il est préférable d'avoir de nombreuses interfaces spécialisées (étroitement ciblées) plutôt qu'une seule universelle. Par exemple, supposons qu'un développeur implémente une interface. Ils n'ont besoin que d'une seule de ses méthodes, mais l'interface comporte neuf méthodes supplémentaires qui ne concernent pas la logique de la méthode requise. Dans ce cas, le développeur devra implémenter dix méthodes d’interface, dont neuf lui sont superflues ! Au lieu de cela, il est préférable de créer dix interfaces différentes que vous pouvez implémenter selon vos besoins. Eh bien, si ce n’est pas dix, du moins plusieurs, chacune avec des méthodes étroitement liées au seul objectif de l’interface. D (Principe d'inversion de dépendance): Le principe dit que les modules de niveau supérieur ne doivent pas dépendre des modules de niveau inférieur. Ce principe stipule également : « L'abstraction ne devrait pas dépendre des détails. Les détails devraient dépendre des abstractions. » Nous devons construire notre logique en nous référant aux interfaces et faire circuler des objets concrets de classes qui implémentent l'interface requise. Par exemple, supposons que nous ayons une interface Cat et quelques implémentations, par exemple Lion et HouseCat . Nous construisons notre logique spécifiquement pour interagir avec l' interface Cat . Nous remplaçons ensuite seulement l'interface par une implémentation spécifique ( Lion ou HouseCat ), mais pas l'inverse.

24. Qu'est-ce qu'une classe, un objet et une interface ?

On rappelle que Java est un langage POO. Autrement dit, les programmes Java sont construits sur la base des interactions entre les objets. Un programme est comme une fourmilière, où chaque fourmi est un objet. Les objets sont des collections de données qui incluent diverses méthodes (fonctions) pour interagir avec ces données internes. Les classes sont des instructions ou des modèles pour créer des objets. Cela signifie que nous pouvons avoir de nombreux objets construits selon les mêmes instructions mais remplis de données différentes (ou identiques). En prenant un exemple tiré de la vie réelle, nous pouvons dire qu'une classe est un plan d'un bâtiment et qu'un objet est un bâtiment construit spécifiquement selon le plan. Les interfaces sont similaires aux classes, mais nous ne pouvons pas les utiliser pour créer des objets. Leur but est d'ajouter de l'abstraction à Java. Plus précisément, ils ajoutent de la flexibilité à la relation entre les classes et les objets. Par flexibilité, nous entendons le polymorphisme et l'abstraction décrits précédemment, qui créent de nombreuses opportunités pour construire l'architecture interne d'une application.

25. Qu'est-ce qu'un cours POJO ? Donnez un exemple d'une telle classe

Un POJO (Plain Old Java Object) est un objet de classe simple qui n'hérite d'aucune classe spécifique et n'implémente aucune interface de service au-delà de celles nécessaires au modèle économique. En d’autres termes, un cours POJO n’est qu’un cours sans exigences particulières. La seule exigence est l’absence de cloches et de sifflets liés à un cadre spécifique. En règle générale, ces classes n'héritent pas d'autres classes (à l'exception des classes POJO dans le même package), n'implémentent pas d'interfaces (parfois une exception est faite pour les interfaces de marqueurs de la bibliothèque standard telles que Serialisable ou Cloneable ), n'utilisent pas d'annotations , et ne dépendent pas de bibliothèques tierces. Notons qu'un POJO peut avoir des méthodes contenant de la logique métier et des constructeurs de toute sorte. Si nous autorisons les annotations qui ne changent pas la sémantique de la classe (c'est-à-dire les annotations dont l'absence ne change pas le but ou la logique de l'objet), alors les POJO peuvent également inclure des entités JPA et des objets DTO désérialisés depuis XML ou JSON , dont les règles sont précisé dans les annotations. Une autre chose à garder à l'esprit concernant les classes POJO est qu'il est bon de remplacer leurs méthodes égales et hashCode car cela peut les aider à mieux remplir leur rôle. Exemple de classe 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. Quels éléments une classe peut-elle contenir ?

Une classe peut contenir les éléments suivants :

• champs d'instance ;
• champs statiques ;
• un bloc d'initialisation ;
• un bloc d'initialisation statique ;
• constructeurs (un constructeur vide est toujours déclaré par défaut) ;
• méthodes;
• méthodes statiques ;
• diverses annotations (qui peuvent être appliquées à la classe elle-même ou à ses éléments constitutifs) ;
• génériques ;
• héritage d'autres classes ( extends ) ou implémentations d'interfaces ( Implements ).

27. Parlez-nous de l'héritage en Java. Quelles sont les spécificités du super mot-clé ?

Ci-dessus, j'ai déjà parlé de l'héritage et du mot-clé super en Java. Je mentionnerai quelques points plus importants :

1. Nous ne pouvons hériter que d’une seule classe : Java n’a pas d’héritage multiple en Java. Avec l’avènement des méthodes par défaut dans Java 8, cette affirmation deviendra très controversée.
2. Les méthodes et champs privés sont également hérités. Ils ne sont tout simplement pas accessibles à partir de la classe enfant (mais si nous avons, par exemple, un champ privé et des getters et setters publics ou protégés , nous pouvons les utiliser pour accéder au champ).
3. les classes finales ne peuvent pas être héritées.
4. Les méthodes final ne peuvent pas être remplacées (mais elles peuvent être héritées et surchargées).
5. les méthodes et variables statiques ne sont pas héritées (car elles sont attachées aux classes et non aux objets).
6. Lors de l'héritage de classes abstraites, leurs méthodes abstraites doivent être implémentées, ou la classe enfant doit également être déclarée abstraite.
7. S'il existe des constructeurs autres que ceux par défaut dans le parent, ils doivent être remplacés dans la classe enfant (mais @Override n'est pas écrit au-dessus d'eux).
8. Vous pouvez étendre le modificateur d'accès aux méthodes remplacées dans la classe enfant : private -> default -> protected -> public .
Les méthodes remplacées dans la classe enfant peuvent générer des exceptions plus étroites, par exemple : Exception -> IOException -> FileNotFoundException.

28. Que sont les signatures de méthode ? Fournir des exemples de signatures correctes et incorrectes

Une signature de méthode est le nom de la méthode plus les types des paramètres d’entrée (l’ordre des paramètres compte). La signature de la méthode n'inclut pas la valeur de retour ni les exceptions levées par la méthode. Exemple de signature correcte :

doSomething(int, double, double)

Exemple de signature incorrecte :

void doSomething(int firstArg, int secondArg) throws Exception

La signature de la méthode, combinée au type de retour et à la liste des exceptions levées, est appelée contrat de méthode . C'est tout pour aujourd'hui! À plus tard!