Análisis de preguntas y respuestas de entrevistas para desarrollador Java. parte 3

¡Hola! Así como es imposible aprender a pilotar un avión sin una formación especial, también es imposible convertirse en desarrollador de Java sin dedicar largas horas a estudiar las bases teóricas necesarias. Hoy trabajaremos exactamente en esto: continuaremos analizando más de 250 preguntas de entrevistas para desarrolladores de Java y, en consecuencia, sus respuestas. Aquí tenéis la primera y segunda parte del análisis. Sí, por supuesto, puedes convertirte en un buen desarrollador de Java sin todas estas preguntas. Sin embargo, si comprende bien los entresijos del lenguaje Java, tendrá una ventaja y lo convertirá en un candidato más deseable a los ojos de su futuro empleador.

20. ¿Qué elementos del lenguaje son responsables de la encapsulación?

Como recordamos, la encapsulación oculta los detalles de implementación de una clase. Es decir, cuando nuestra clase se usa externamente, el contenido y la lógica internos no son obvios. ¿Y qué elementos del lenguaje son responsables de esto? Naturalmente, ¡ modificadores de acceso ! Marcamos lo que necesitamos ocultar con el modificador privado . Por ejemplo, campos privados de una clase o algunos métodos internos que ayudan a implementar cierta funcionalidad interna. Y a aquello a lo que queremos brindarle acceso externo le agregamos el modificador de acceso público . Por ejemplo, un método responsable de proporcionar alguna funcionalidad (dentro de la cual se pueden usar muchos métodos privados) o los mismos getters y setters para acceder a los campos privados de una clase. Ah, y también tenemos los modificadores default y protected , que se pueden usar para una configuración de acceso más flexible y específica a partes seleccionadas de la clase.

21. ¿Qué elementos del lenguaje son responsables de la herencia?

La herencia es un mecanismo que le permite crear clases basadas en otra clase. En Java, la palabra clave extends se utiliza para este propósito . Por ejemplo, tenemos una determinada clase Cat y queremos crear su sucesora: Lion . En código se verá así:

public class Lion extends Cat

Y esto significa que la clase Lion hereda todos los métodos y variables de la clase Cat , excepto los estáticos. Además, los elementos del lenguaje responsables de la herencia incluyen super . Esta es una referencia similar a this , pero mientras this se refiere al objeto en el que se llamó, super se refiere al objeto principal actual. Normalmente se utiliza super :

1. Para llamar a un constructor de superclase: por ejemplo, la clase Cat tiene un nombre de variable interna que debe inicializarse en el constructor. En el constructor de la clase Lion se vería así:

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

2. Para acceder a campos y métodos principales: por ejemplo, en la clase Cat tenemos un campo de edad inicializado :

   public class Cat {
      int age = 10;

Al mismo tiempo, tenemos el mismo campo inicializado en Lion :

public class Lion extends Cat {
   int age = 15;

Y si queremos acceder a la variable de edad del objeto padre desde el objeto Lion , debemos hacerlo a través de super :

super.name

22. ¿Qué elementos del lenguaje son responsables del polimorfismo?

El polimorfismo es la capacidad de un objeto con una firma de adoptar muchas formas (múltiples implementaciones). Podemos decir con seguridad que en Java las palabras clave implements y extends son responsables del polimorfismo . implements - cuando creamos nuestra interfaz, implementamos una de sus posibles formas en alguna clase, pero no es la única forma, ¿verdad? Recordemos cómo se ven los implementos de implementación :

public class Cat implements Animal

Y en la clase Cat debemos implementar todos los métodos abstractos presentados en la interfaz Animal . Lo mismo ocurre con la herencia: en una clase descendiente podemos anular una implementación ya existente de un método. Por ejemplo: varios descendientes -> varias anulaciones diferentes del mismo método. Bueno, o la superclase era abstracta y tiene un método determinado que debe implementarse de manera especial para cada uno de sus descendientes. Es decir, podemos decir que el método adoptará muchas formas. Además, con esto nos puede ayudar la anotación @Override , que se coloca encima de los métodos implementados e indica que queremos implementar o anular (si la implementación ya existe en la superclase) uno u otro método de la superclase o interfaz. Es opcional y se utiliza para facilitar la detección de errores. Con esta anotación, le indica al compilador que desea anular/implementar un método de superclase/interfaz, y se asegurará de que no cometa errores en la firma del método.

23. ¿Qué es SÓLIDO? Dar ejemplos

SOLID es un acrónimo de los Cinco Principios Básicos de Diseño para POO, acuñados por Robert Martin. S - Principio de responsabilidad única : el principio de responsabilidad única, que establece que una clase debe tener un solo objetivo y un propósito único. Es decir, no debes crear clases que hagan de todo. En este caso, puedes reproducir el antipatrón “Objeto Divino”. Si tiene un objeto Cat , debe contener métodos que interactúen solo con su funcionalidad interna y no con lógica de negocios que no sea relevante para esta instancia. Por ejemplo, algún tipo de guardado de objetos de este tipo en alguna parte. Esta funcionalidad externa (relativa a Cat ) debe transferirse a otras clases, algunos servicios cuya tarea es proporcionar lógica de negocios para objetos de este tipo. O - Principio abierto-cerrado - principio de apertura/cerramiento. Significa que las entidades de software (clases, interfaces) deben estar abiertas a la extensión, pero cerradas a la modificación. Por ejemplo, necesitábamos una funcionalidad similar a la funcionalidad de la clase Cat ya existente , pero ligeramente diferente. En lugar de cambiar la funcionalidad de la clase Cat , rompiendo los lugares donde ya se usa, usamos herencia o composición . Como resultado, logramos nuestro objetivo con la funcionalidad modificada de la clase Cat , pero al mismo tiempo no la cambiamos ni rompimos nada. L - Principio de sustitución de Liskov - Principio de sustitución de Barbara Liskov. El principio establece que una función que usa un tipo base debería poder usar subtipos del tipo base sin saberlo. Por ejemplo, nuestra clase Cat debería ser intercambiable con cualquiera de sus descendientes, digamos Lion , sin cambiar fundamentalmente el comportamiento. La lógica general (comportamiento) sigue siendo la misma, pero los detalles de la implementación de tal o cual funcionalidad cambian. I - Principio de segregación de interfaces : el principio de separación de interfaces. Este principio establece que es mejor tener muchas interfaces especializadas (con un enfoque limitado) que una universal. Por ejemplo, un usuario implementa alguna interfaz, de la cual solo necesita este método, pero esta interfaz tiene nueve métodos más que no tienen nada que ver con la lógica del método deseado. En este caso, el usuario deberá implementar diez métodos de interfaz, ¡nueve de los cuales son innecesarios para él! En cambio, es mejor crear diez interfaces diferentes que puedan implementarse si es necesario. Bueno, o no diez, sino varios, que tendrán métodos muy relacionados con el propósito común de la interfaz. D - Principio de inversión de dependencia— el principio de inversión de dependencia. El principio establece que los módulos de niveles superiores no deben depender de módulos de niveles inferiores. Este principio también se describe como "la abstracción no debe depender de los detalles, los detalles deben depender de la abstracción". Es decir, debemos construir nuestra lógica haciendo referencia a interfaces, y solo entonces pasar objetos específicos a esta funcionalidad, cuyas clases implementan la interfaz requerida. Por ejemplo, si tenemos una interfaz Cat y algunas de sus implementaciones, digamos Lion y HomeCat , construimos nuestra lógica de interacción específicamente con el tipo de interfaz Cat , y solo entonces la sustituimos por una implementación específica de Lion o HomeCat , pero no al revés.

24. ¿Qué es una clase, objeto, interfaz?

Como recordamos, Java es un lenguaje OOP. Es decir, los programas Java se basan en la interacción entre objetos. Resulta que el programa es como un hormiguero, donde cada hormiga es un objeto. Los objetos son algunos datos agrupados que contienen varios métodos (funciones) para interactuar con estos datos internos. Y las clases son instrucciones, plantillas para crear objetos. Es decir, puede haber muchos objetos construidos según la misma instrucción, llenos de valores de datos diferentes o idénticos. Para dar un ejemplo de la vida, podemos decir que una clase es un dibujo de un edificio y un objeto es un edificio creado específicamente en base a este dibujo. Las interfaces son análogas a las clases con la diferencia de que no se pueden crear objetos con ellas. Su objetivo es añadir un elemento de abstracción a Java. Más precisamente, para agregar flexibilidad en las relaciones entre clases y objetos. Por flexibilidad nos referimos al polimorfismo y la abstracción descritos anteriormente, que a su vez abren muchas oportunidades para construir la arquitectura interna de la aplicación.

25. ¿Qué es una clase POJO? Dé un ejemplo de tal clase.

POJO - Plain Old Java Object - un buen objeto Java antiguo: un objeto simple de una clase que no se hereda de ninguna clase específica y no implementa ninguna interfaz de servicio más allá de las necesarias para el modelo de negocio. En otras palabras , una clase POJO es sólo una clase sin requisitos especiales. El único requisito es la ausencia de diversos detalles vinculados a un marco específico. Como regla general, dichas clases no heredan de otras clases (excepto las clases POJO del mismo paquete), no implementan interfaces (a veces se hace una excepción para las interfaces de marcadores de la biblioteca estándar, como Serializable o Cloneable ), no usan anotaciones. y no depender de bibliotecas de terceros. Pero observo que los POJO pueden tener métodos con lógica empresarial y constructores de cualquier tipo. Si permite anotaciones que no realizan cambios en la semántica de la clase (sin las cuales el propósito del objeto y la lógica de su operación no cambiarán), los POJO también pueden incluir entidades de entidad JPA y objetos DTO deserializados de XML o JSON . cuyas reglas se especifican en las anotaciones. También es recomendable anular iguales y hashCode para las clases POJO , ya que esto puede ayudarlas a desempeñar mejor su función. Ejemplo de clase 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. ¿Qué elementos puede contener una clase?

La clase puede contener los siguientes elementos:

• campos de clase;
• campos de clase estática;
• bloque de inicialización;
• bloque de inicialización estática;
• constructores (vacío siempre se define por defecto);
• métodos;
• métodos estáticos;
• varias anotaciones (que pueden colgar encima de la clase misma o de sus componentes);
• genéricos ;
• herencia de otras clases ( extiende ) o implementación de interfaces ( implementa ).

27. Explique la herencia en Java. ¿Cuáles son los beneficios de utilizar la súper palabra clave?

Arriba ya hablé sobre la herencia y la super palabra clave en Java. Permítanme mencionar algunos puntos más importantes:

1. Es posible heredar sólo una clase: no existe herencia múltiple en Java (pero con la llegada de los métodos predeterminados en Java 8, esta afirmación se volverá muy controvertida).
2. Los métodos y campos privados también se heredan, simplemente no tendrán acceso a ellos por parte del heredero (pero si, por ejemplo, tenemos un campo privado y hay captadores y definidores públicos o protegidos para él, se puede trabajar con el campo). a través de ellos).
3. las clases finales no se heredan.
4. Los métodos finales no se anulan (pero se pueden heredar y sobrecargar).
5. Los métodos estáticos y las variables no se heredan (ya que no están vinculados a objetos, sino a clases).
6. Al heredar de clases abstractas, se requiere la implementación de sus métodos abstractos, o la clase actual también debe declararse abstracta.
7. Si hay constructores no predeterminados en la clase principal, se deben anular en la clase secundaria (pero @Override no se escribe sobre ellos).
8. Los métodos anulados en el descendiente se pueden ampliar con un modificador de acceso: privado -> predeterminado -> protegido -> público .
9. Los métodos anulados en el descendiente pueden limitar las excepciones que se escriben, por ejemplo: Excepción -> IOException -> FileNotFoundException.

28. ¿Qué es la firma de un método? Dar ejemplos de firmas correctas e incorrectas.

La firma de un método es el nombre del método más los tipos de parámetros entrantes (y el orden de los parámetros importa). La firma del método no incluye el valor de retorno ni las excepciones que arroja. Ejemplo de firma correcta:

doSomething(int, double, double)

Un ejemplo de firma incorrecta:

void doSomething(int firstArg, int secondArg) throws Exception

La firma del método, combinada con el tipo de retorno y la lista de excepciones que se generan, se denomina contrato de método . Eso es todo por hoy. ¡Hasta luego!