sirve - this en java
¿Por qué se te permite llamar a un constructor de otro? (6)
Como complemento a las otras respuestas, me gustaría compartir otro uso para llamar a un constructor de un constructor que uso a menudo.
Otra estrategia de encadenamiento de constructores que me parece útil es proporcionar implementaciones / autoinyección predeterminadas para interfaces.
public class Foo {
private readonly ILogger _logger;
//Default implementation for most cases
public Foo() : this(new DefaultLoggerImplementation()) {}
//DI Constructor that allows for different implementations of ILogger
//(Or Mocks in testing)
public Foo(ILogger logger)
{
_logger = logger;
}
public void Log(string message)
{
_logger.log(message);
}
}
De esta forma, si tiene una implementación predeterminada para una interfaz, se inyecta automáticamente a través de un new Foo()
Si tiene un caso con diferente comportamiento de ILogger
, es fácilmente inyectable, esto también promueve la capacidad de simular la interfaz en el marco de prueba de su unidad.
Estaba viendo otras preguntas en SO, pero realmente no vi una explicación para mi pregunta. Leí que llamar a un constructor de otro constructor (usando la palabra clave this) era válido , pero no entendía por qué era válido.
Previamente, pensé que solo un constructor podría actuar por objeto. El encadenamiento de constructores parece romper esta lógica, ya que al llamar a un constructor, ejecuta otro en conjunción con el constructor original y específico. ¿Por qué funciona el encadenamiento de constructores?
El hecho de que la confusión se origina en cada instancia debe llamar a un coordinador que tiene toda la razón. El constructor encadenado a otro se utiliza para evitar la duplicación y la simplicidad del código porque copiar el mismo código es realmente sobrecargado. A veces tal vez necesitamos dos constructores, el primero solo toma dos parámetros, el otro toma tres parámetros. Pero, tres parámetros -ctor usa las mismas variables de dos parámetros -ctor. ¿Prefiere copiar y pegar asignaturas iguales o simplemente llamar al otro coordinador por this
?
Encadenamos (llamamos) a un constructor desde otro dentro de la misma clase para que podamos evitar la duplicación del código. Sin encadenar a cada constructor, terminamos repitiendo los detalles del negocio y eso lleva a la duplicación del código y también es difícil mantener el código.
Imagina que estás creando un Bus.
public class Bus {
int noOfSeats;
String busColor;
public Bus() {
this(40); //// Using another constructor and proceeding with default values..
}
public Bus(int seats) {
this(seats,"red"); // Using another constructor and proceeding..
}
public Bus(int seats, String color) {
this.noOfSeats = seats;
this.busColor = color;
}
}
Y la persona que usa esta clase puede usar solo constructor a la vez, mientras que usted está usando encadenamiento internamente. Imagine que tiene un método que inicializa cosas con valores predeterminados y lo llama en el constructor. No hay nada de malo en eso, ¿verdad?
Solo para aclarar, la persona que crea el objeto llama solo a un constructor. El constructor invocado llama a otros que es interno a esa clase.
Los constructores delegados reducen la cantidad de código duplicado, ya que puede explotar la funcionalidad configurada en un constructor llamándolo desde otro.
Hasta que esta característica se diseñó en idiomas, tuvimos que confiar en las funciones de tipo "inicialización" que fueron llamadas desde los constructores. Eso fue un dolor por dos razones (i) nunca se podía garantizar que las funciones solo fueran llamadas desde los constructores, y (ii) llamar a los métodos de clase desde los constructores es siempre un "olor" de diseño.
No es un desarrollador de Java aquí, pero en Python esto también está permitido y es bastante normal.
Siempre que herede una clase, es posible que desee llamar al constructor de la clase principal antes de agregar sus propias cosas y recetas.
Esto le permite beneficiar las características de construcción de la clase padre. Cuando no sabe exactamente qué es lo que hace la clase principal, siempre lo llama primero para evitar que se rompan las características y métodos de clase de los padres.
Permite aclarar la lógica y reducir el código.
Es razonable encadenar a los constructores, la versión con menos parámetros llama a la versión con más parámetros. Deja muy claro lo que está sucediendo, y toda la "lógica" real (más allá de los valores por defecto) está en un solo lugar. Por ejemplo:
public class Foo {
private static final int DEFAULT_X =10;
private static final int DEFAULT_Y =20;
private int x;
private int y;
private int precomputedValue;
public Foo(int x, int y) {
this.x = x;
this.y = y;
precomputedValue = x * y;
}
public Foo(int x) {
this(x, DEFAULT_Y);
}
public Foo() {
this(DEFAULT_X, DEFAULT_Y)
}
}