Analyse des questions et réponses des entretiens pour développeur Java. Partie 11

Bonjour! Même le navire le plus rapide sans cap dérivera simplement le long des vagues. Si vous lisez mon article maintenant, vous avez définitivement un objectif. L'essentiel n'est pas de s'égarer, mais de suivre sa ligne jusqu'au bout - de devenir développeur Java. Aujourd'hui, je souhaite poursuivre mon analyse de plus de 250 questions destinées aux développeurs Java, qui vous aideront à combler certaines des lacunes de la théorie.

97. Des conditions de redéfinition de l'accord sont-elles imposées lors de la redéfinition d'Equals ?

La méthode equals() substituée doit respecter les conditions (règles) suivantes :

• réflexivité - pour toute valeur x, une expression comme x.equals(x) doit toujours renvoyer true (quand x != null ).

• symétrie - pour toutes les valeurs de x et y, une expression de la forme x.equals(y) doit renvoyer true uniquement si y.equals(x) renvoie true .

• transitivité - pour toutes les valeurs de x , y et z , si x.equals(y) renvoie true et y.equals(z) renvoie également true , alors x.equals(z) doit renvoyer true .

• cohérence - pour toutes les valeurs de x et y, un appel répété à x.equals(y) renverra toujours la valeur de l'appel précédent à cette méthode, à condition que les champs utilisés pour comparer les deux objets n'aient pas changé entre les appels .

• comparaison null - pour toute valeur x, l'appel de x.equals(null) renverra false .

98. Que se passe-t-il si vous ne remplacez pas Equals et HashCode ?

Dans ce cas, hashCode() renverra un nombre généré en fonction de l'emplacement mémoire dans lequel l'objet donné est stocké. Autrement dit, deux objets avec exactement les mêmes champs recevront des valeurs différentes lors de l'appel d'un hashCode() non remplacé (après tout, ils sont stockés dans des emplacements mémoire différents). La fonction equals() non remplacée compare les références pour voir si elles pointent vers le même objet ou non. Autrement dit, la comparaison est effectuée via == , et dans le cas d'objets avec les mêmes champs, elle renverra toujours false . True ne le sera que lors de la comparaison des références au même objet. Il est parfois logique de ne pas outrepasser ces méthodes. Par exemple, vous souhaitez que tous les objets d'une certaine classe soient uniques et remplacer ces méthodes ne fera que gâcher la logique de l'unicité. L'essentiel est de comprendre les nuances des méthodes annulées et non annulées et d'utiliser les deux approches en fonction de la situation.

99. Pourquoi la symétrie n'est-elle vraie que si x.equals(y) renvoie vrai ?

Une question un peu étrange. Si l’objet A est égal à l’objet B, alors l’objet B est égal à l’objet A. Si B n’est pas égal à l’objet A, alors comment l’inverse est-il possible ? C'est une logique simple.

100. Qu'est-ce qu'une collision dans HashCode ? Comment y faire face?

Une collision hashCode est une situation dans laquelle deux objets différents ont la même valeur hashCode . Comment est-ce possible? Le fait est que le hashcode est mappé au type Integer , qui à son tour va de -2147483648 à 2147483647, soit environ 4 milliards d'entiers différents. Cette gamme est immense, mais elle n’est pas infinie. Par conséquent, des situations sont possibles lorsque deux objets complètement différents ont le même code de hachage. C'est hautement improbable, mais possible. Une fonction de hachage mal implémentée peut également augmenter la fréquence des codes de hachage identiques, qui renverront par exemple des nombres dans une petite plage, ce qui augmentera le risque de collisions. Pour lutter contre une collision, vous devez avoir une bonne implémentation de la méthode hashCode afin que la propagation des valeurs soit maximale et que le risque de répétition des valeurs soit minime.

101. Que se passe-t-il si un élément participant à un contrat HashCode change de valeur ?

Si un élément impliqué dans le calcul du code de hachage a été modifié, alors le code de hachage de l'objet lui-même sera modifié (si la fonction de hachage est bonne). Par conséquent, dans HashMap , il est recommandé d'utiliser des objets immuables (inchangeables) comme clé, car leur état interne (champs) ne peut pas être modifié après la création. En conséquence, leur code de hachage n'est pas non plus converti après la création. Si vous utilisez un objet mutable comme clé, lorsque vous modifiez les champs de cet objet, son code de hachage changera et, par conséquent, vous pourrez perdre cette paire dans le HashMap . Après tout, il sera stocké dans le compartiment pour le code de hachage d'origine, et après l'avoir modifié, il sera recherché dans un autre compartiment.

102. Écrivez les méthodes Equals et HashCode pour la classe Student, qui comprend des champs de nom de chaîne et d'âge int.

public class Student {
int age;
String name;

 @Override
 public boolean equals(final Object o) {
   if (this == o) {
     return true;
   }
   if (o == null || this.getClass() != o.getClass()) {
     return false;
   }

   final Student student = (Student) o;

   if (this.age != student.age) {
     return false;
   }
   return this.name != null ? this.name.equals(student.name) : student.name == null;
 }

 @Override
 public int hashCode() {
   int result = this.age;
   result = 31 * result + (this.name != null ? this.name.hashCode() : 0);
   return result;
 }
}

Équivaut à:

• Tout d’abord, nous comparons directement les liens, car si les liens renvoient au même objet, à quoi bon continuer la vérification ? De toute façon, tout sera vrai .

• Vérification de null et des types de classe correspondants, car si un objet est un argument de null ou d'un autre type, cela signifie que les objets ne sont pas égaux - false .

• Conversion de l'objet argument en un seul type (au cas où il s'agirait d'un objet du type parent).

• Comparaison d'un champ de classe primitive (après tout, une comparaison via =! suffit ), si le champ n'est pas égal - false .

• Vérification d'un champ non primitif pour null et égal (dans String, la méthode est remplacée et se comparera correctement), si les deux champs sont nuls ou égaux , alors la vérification se termine et la méthode renvoie true .

Code de hachage :

• Définition de la valeur initiale du code de hachage sur la primitive d'âge de l'objet .

• Multiplier le code de hachage actuel par 31 (pour une plus grande diffusion) et y ajouter le code de hachage d'un champ de chaîne non primitif (s'il n'est pas nul).

• Renvoyer le résultat.

• À la suite de ce remplacement de code de hachage, les objets portant le même nom et les mêmes valeurs int renverront toujours la même valeur.

103. Quelle est la différence entre utiliser if (obj instanceof Student) et if (getClass() == obj.getClass()) ?

Regardons ce que fait chaque approche :

• instanceof vérifie si une référence d'objet sur le côté gauche est une instance d'un type sur le côté droit ou un sous-type de celui-ci.

• getClass() == ... vérifie l'identité du type.

Autrement dit, si getClass() vérifie l'identité complète d'une classe, alors instanceof retournera true même si l'objet n'est qu'un sous-type, ce qui peut nous donner plus de flexibilité lors de l'utilisation active du polymorphisme. En fait, les deux approches sont bonnes si vous comprenez les caractéristiques de leur travail et les appliquez aux bons endroits.

104. Donnez une brève description de la méthode clone().

Clone() est une méthode de la classe Object dont le but est de créer et de renvoyer un clone de l'objet courant (une copie de l'objet courant). Pour l'utiliser, vous devez implémenter l' interface Cloneable Marker :

Student implements Cloneable

Et remplacez la méthode clone() elle-même :

@Override
protected Object clone() throws CloneNotSupportedException {
 return super.clone();
}

Après tout, dans la classe Object , il est protégé, c'est-à-dire qu'il ne sera visible que dans la classe Student elle-même , mais pas visible pour les classes de l'extérieur.

105. Quelle est la particularité de la méthode clone() travaillant avec les champs d'un objet de type référence ?

Lors du clonage d'objets, seules les valeurs primitives et la valeur des références d'objet sont copiées. Cela signifie que si un objet possède un lien vers un autre objet dans son champ interne, alors seul ce lien sera cloné, mais cet autre objet lui-même ne sera pas cloné. En fait, c’est ce qu’ils appellent le clonage de surface. Eh bien, que se passe-t-il si vous avez besoin d'un clonage à part entière avec le clonage de tous les objets imbriqués ? Comment s'assurer qu'il ne s'agit pas de copies de liens, mais de clones à part entière d'objets avec d'autres cellules mémoire occupées dans le tas ? En fait, tout est assez simple - pour cela, vous devez également remplacer la méthode clone() dans chaque classe de ces objets internes et ajouter une interface de marqueur - Cloneable . Ensuite, ce ne seront pas les références aux objets qui seront copiées, mais les objets eux-mêmes, car désormais ils ont aussi la capacité de se copier.

Des exceptions

106. Quelle est la différence entre une erreur et une exception ?

Les exceptions et les erreurs sont des sous-classes de la classe Throwable . Cependant, ils ont leurs différences. L'erreur indique un problème qui se produit principalement en raison de ressources système insuffisantes. Et notre application ne doit pas détecter ce type de problèmes. Certains des exemples d’erreurs sont un crash du système et une erreur de mémoire insuffisante. Les erreurs se produisent principalement au moment de l’exécution car elles sont de type non vérifié. Les exceptions sont des problèmes qui peuvent survenir au moment de l'exécution et au moment de la compilation. Cela se produit généralement dans le code écrit par les développeurs. Autrement dit, les exceptions sont plus prévisibles et dépendent davantage de nous en tant que développeurs. Dans le même temps, les erreurs sont plus aléatoires et plus indépendantes de nous, mais dépendent plutôt de problèmes liés au système lui-même dans lequel notre application s'exécute.

107. Quelle est la différence entre coché et décoché, exception, lancer, lancers.

Comme je l'ai dit plus tôt, une exception est une erreur lors de l'exécution du programme et lors de la compilation survenue dans le code écrit par le développeur (en raison d'une situation anormale). Checked est un type d’exception qui doit toujours être géré à l’aide du mécanisme try-catch ou lancé dans les méthodes ci-dessus. Throws est utilisé dans l'en-tête de la méthode pour indiquer les exceptions possibles levées par la méthode. Autrement dit, il s'agit du mécanisme permettant de « lancer » des exceptions dans les méthodes ci-dessus. Unchecked est un type d’exception qui n’a pas besoin d’être géré et qui est généralement moins prévisible et moins susceptible de se produire. Cependant, ils peuvent également être traités si vous le souhaitez. Throw est utilisé lors du lancement manuel d'une exception, par exemple :

throw new Exception();

108. Quelle est la hiérarchie des exceptions ?

La hiérarchie des exceptions est très large et étendue, trop étendue même pour en parler ici. Par conséquent, nous ne considérerons que ses liens clés : Ici, tout en haut de la hiérarchie, nous voyons la classe - Throwable - une classe générale, l'ancêtre de la hiérarchie des exceptions, qui à son tour est divisée en :

• Erreur - erreurs critiques et incontrôlables.
• Exception - exceptions vérifiées.

L'exception est divisée en diverses exceptions d'exécution non vérifiées et en diverses exceptions vérifiées.

109. Qu'est-ce qu'une exception cochée et non cochée ?

Comme je le disais avant:

• Vérifié - exceptions que vous devez gérer d'une manière ou d'une autre, c'est-à-dire soit les traiter dans un bloc try - catch , soit les « transmettre » à la méthode ci-dessus. Pour ce faire, dans la signature de la méthode, après avoir répertorié les arguments de la méthode, vous devez utiliser le mot-clé trows <exception type> , qui indique aux utilisateurs de la méthode que la méthode peut lever cette exception (quelque chose comme un avertissement) et transfère le responsabilité de gérer l’exception aux utilisateurs de cette méthode.

• Non vérifié - exceptions qui n'ont pas besoin d'être gérées, car elles ne sont pas vérifiées au moment de la compilation et, en règle générale, sont plus imprévisibles. Autrement dit, la principale différence avec check est que pour eux, ces mécanismes d'essai ou de lancement fonctionnent de la même manière, mais ils ne sont pas obligatoires.

101. Écrivez un exemple d'interception et de gestion d'une exception dans un bloc try-catch d'une méthode

try{                                                 // начало блока перехвата
 throw new Exception();                             // ручной бросок исключения
} catch (Exception e) {                              // данное исключение и его потомки будут перехватываться
 System.out.println("Упс, что-то пошло не так =("); // вывод некоторого исключения в консоль
}

102. Écrivez un exemple de détection et de gestion d'une exception en utilisant vos propres exceptions

Tout d'abord, écrivons notre propre classe d'exception, qui hérite d' Exception et remplaçons son constructeur par un message d'erreur :

public class CustomException extends Exception {

 public CustomException(final String message) {
   super(message);
 }
}

Eh bien, nous allons le lancer manuellement et l'intercepter comme dans la question précédente :

try{
 throw new CustomException("Упс, что-то пошло не так =(");
} catch (CustomException e) {
 System.out.println(e.getMessage());
}

Et encore une fois, lorsque vous l'exécuterez, vous obtiendrez le résultat suivant sur la console : Vous pouvez en savoir plus sur les exceptions ici . Eh bien, c'est tout pour aujourd'hui ! Rendez-vous dans la prochaine partie !