Al escribir proyectos complejos, es esencial desarrollar una buena cultura de código. El uso de objetos inmutables y consistentes es uno de los más importantes.  Puede ignorar esto y escribir objetos complejos como estándar, pero será una fuente importante de errores cuando el proyecto crezca lo suficiente.  En mi  anterior, mostré cómo podemos mejorar la consistencia y confiabilidad de los objetos estándar. En pocas palabras: artículo  Agregar validaciones al establecer valores  Use   para cada campo anulable java.util.Optional  Coloque las mutaciones complejas en un lugar adecuado, para la clase responsable misma.  Pero esas acciones no son suficientes para hacer objetos completamente confiables. En este artículo, mostraré cómo hacer que los objetos sean inmutables y hacerlos de manera elocuente y eficiente.  El problema  Si creamos un objeto serializable simple con un constructor/getters/setters predeterminado, está bien hacerlo de la manera estándar. Pero supongamos que escribimos algo más complejo. Y lo más probable es que se use en innumerables lugares.  Por ejemplo, se usa en HashMaps y tal vez en un entorno de subprocesos múltiples. Entonces, ya no parece una buena idea escribirlo de la manera predeterminada.   no es gran cosa, y un estado inconsistente entre subprocesos no hará esperar mucho. Romper HashMap  Las primeras   que vienen a la mente cuando se piensa en hacer objetos inmutables son: cosas  No haga métodos setter  Hacer que todos los campos sean definitivos  No comparta instancias con objetos mutables  No permita que las subclases anulen los métodos (lo omitiré en este artículo)  Pero, ¿cómo vivir con ese tipo de objeto? Cuando necesitamos cambiarlo, necesitamos hacer una copia; ¿Cómo podemos hacerlo bien sin copiar y pegar código y lógica cada vez?  Algunas palabras sobre nuestras clases de ejemplo  Digamos que tenemos Cuentas. Cada cuenta tiene una   ,   y   . Las cuentas se pueden verificar por correo electrónico. Cuando el estado es   , no esperamos que se complete el correo electrónico. Pero cuando está   o   , se debe llenar el correo electrónico.  id status email CREATED VERIFIED INACTIVE   public enum AccountStatus { CREATED, VERIFIED, INACTIVE }  La implementación canon   : Account.java   public class Account { private final String id; private final AccountStatus status; private final String email; public Account(String id, AccountStatus status, String email) { this.id = id; this.status = status; this.email = email; } // equals / hashCode / getters }  Imaginemos que hemos creado una cuenta. Luego, en algún lugar de la lógica comercial, necesitamos cambiar un correo electrónico.   var account = new Account("some-id", CREATED, null);  ¿Cómo podemos hacer eso? La forma predeterminada no funcionará, no podemos tener setters con una clase inmutable.   account.setEmail("example@example.com");// we can not do that, we have no setters  La única forma de hacerlo es crear una nueva instancia y colocar los valores anteriores del constructor:   var withEmail = new Account(account.getId(), CREATED, "example@example.com");  Pero no es la mejor manera de cambiar el valor de un campo, produce mucho copiar/pegar y la clase Account no es responsable de su consistencia.  Solución  La solución sugerida es proporcionar métodos de mutación de la clase Cuenta e implementar la lógica de copia dentro de la clase responsable. Además, es esencial agregar las validaciones requeridas y el uso de Opcional para el campo de correo electrónico, por lo que no tendremos problemas de coherencia o NPE.  Para construir un objeto, uso el patrón 'Builder'. Es bastante famoso y hay muchos complementos para que su IDE lo genere automáticamente.   public class Account { private final String id; private final AccountStatus status; private final Optional<String> email; public Account(Builder builder) { this.id = notEmpty(builder.id); this.status = notNull(builder.status); this.email = checkEmail(builder.email); } public Account verify(String email) { return copy() .status(VERIFIED) .email(of(email)) .build(); } public Account changeEmail(String email) { return copy() .email(of(email)) .build(); } public Account deactivate() { return copy() .status(INACTIVE) .build(); } private Optional<String> checkEmail(Optional<String> email) { isTrue( notNull(email).map(StringUtils::isNotBlank).orElse(false) || this.status.equals(CREATED), "Email must be filled when status %s", this.status ); return email; } public static final class Builder { private String id; private AccountStatus status; private Optional<String> email = empty(); private Builder() { } public static Builder account() { return new Builder(); } public Builder id(String id) { this.id = id; return this; } public Builder status(AccountStatus status) { this.status = status; return this; } public Builder email(Optional<String> email) { this.email = email; return this; } public Account build() { return new Account(this); } } // equals / hashCode / getters }  Como puede ver, hay una   de método privado en nuestra clase que devuelve   con una copia exacta. Eso elimina el copiar y pegar de todos los campos, sin embargo, es crucial que este método no sea accesible desde fuera de   porque, con ese Builder afuera, perdemos el control sobre el estado y la consistencia. copy Builder Account.java  Cambiar de cuenta de una forma nueva  Ahora, vamos a crear una cuenta:   var account = account() .id("example-id") .status(CREATED) .email((empty()) .build();  Cuando necesitamos cambiar un correo electrónico, no necesitamos ser responsables de crear una copia, simplemente llamamos a un método desde   en sí: Account   var withNewEmail = account.changeEmail("new@new.com");  Demostración de eso en una prueba unitaria:   @Test void should_successfully_change_email() { // given var account = account() .id("example-id") .status(VERIFIED) .email(of("old@old.com")) .build(); var newEmail = "new@new.com"; // when var withNewEmail = account.changeEmail(newEmail); // then assertThat(withNewEmail.getId()).isEqualTo(account.getId()); assertThat(withNewEmail.getStatus()).isEqualTo(account.getStatus()); assertThat(withNewEmail.getEmail()).isEqualTo(of(newEmail)); }  Para verificar una cuenta, no creamos una copia con estado   y un nuevo correo electrónico. Simplemente llamamos al método   , que no solo creará una copia para nosotros, sino que también verificará la validez de un correo electrónico. VERIFIED verify   @Test void should_successfully_verify_account() { // given var created = account() .id("example-id") .status(CREATED) .build(); var email = "example@example.com"; // when var verified = created.verify(email); // then assertThat(verified.getId()).isEqualTo(created.getId()); assertThat(verified.getStatus()).isEqualTo(VERIFIED); assertThat(verified.getEmail().get()).isEqualTo(email); }  Conclusión  Vivir con objetos inmutables, consistentes y confiables es difícil, pero en la forma adecuada, puede volverse mucho más fácil.  Al implementar uno,  :  no te olvides de  Hacer que todos los campos sean definitivos  No proporcionar setters  No compartir enlaces a objetos mutables  No permita que las subclases anulen los métodos.  Proporcione métodos de mutación de su clase  Implementar el    el método dentro de la clase responsable que devuelve un   y utilícelo para crear nuevas instancias dentro de su clase.  privado copy Builder  Mantenga la consistencia de los campos mediante el uso de validaciones en los valores  Use   con campos anulables Optional  Puede encontrar el ejemplo completamente funcional con más pruebas unitarias en   . GitHub  Foto principal de   en  Adam Nieścioruk Unsplash

Canon

Oracle

2022 - HackerNoon Contributor of the Year - Backend

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Software Engineering

Nominated for 2022 - HackerNoon Contributor of the Year - Monitoring

Nominated for 2022 - HackerNoon Contributor of the Year - Software Engineering

Nominated for 2022 - HackerNoon Contributor of the Year - Clean Code

Nominated for 2022 - HackerNoon Contributor of the Year - Debugging

Nominated for 2022 - HackerNoon Contributor of the Year - Backend

Nominated for 2022 - HackerNoon Contributor of the Year - Java

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Aprenda a vivir con objetos inmutables y confiables en Java

Aprenda a vivir con objetos inmutables y confiables en Java

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps