Capítulo 58. Constructores mínimos
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Steve Freeman
Un patrón que veo con regularidad es el trabajo significativo realizado en el constructor: tomar un conjunto de argumentos y convertirlos en valores para los campos. A menudo tiene este aspecto:
public class Thing {
private final Fixed fixed;
private Details details;
private NotFixed notFixed;
// more fields
public Thing(Fixed fixed,
Dependencies dependencies,
OtherStuff otherStuff) {
this.fixed = fixed;
setup(dependencies, otherStuff);
}
}
Supongo que setup inicializa los campos restantes basándose en dependencies y otherStuff, pero no me queda claro en la firma del constructor qué valores son necesarios exactamente para crear una nueva instancia. Tampoco es obvio qué campos pueden cambiar durante la vida del objeto, ya que no se pueden hacer final a menos que se inicialicen en un constructor. Por último, esta clase es más difícil de probar unitariamente de lo que debería, porque instanciarla requiere crear la estructura adecuada en los argumentos que se pasarán a setup.
Peor aún, de vez en cuando veía constructores como éste:
public class Thing {
private Weather currentWeather;
public Thing(String weatherServiceHost) {
currentWeather = getWeatherFromHost(weatherServiceHost);
}
}
que requiere una conexión a Internet ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access