Dilo una vez y solo una vez

TL;DR: Evite validaciones de correo electrónico duplicadas.

Problemas abordados

• Lógica de validación de correo electrónico repetida en varios lugares.
• Riesgo de reglas de validación inconsistentes.
• Violación de biyección
• Obsesión primitiva
• Optimización prematura

Códigos relacionados con olores

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-x-i7r34uj

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxv

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiv

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxxvi

Código Smell 20: Optimización prematura

Pasos

1. Identifique dónde se duplica la lógica de validación de correo electrónico.

   
   

2. Cree una clase Email Address para encapsular las reglas de validación.

   
   

3. Refactorizar el código para utilizar la clase Email Address en lugar de cadenas sin formato.

Código de muestra

Antes

 public class Person { private String emailAddress; // Primitive Obsession public void setEmailAddress(String emailAddress) { // Duplicated code if (!emailAddress.matches( "^[\\w.%+-]+@[\\w.-]+\\.[a-zA-Z]{2,}$")) { throw new IllegalArgumentException( "Invalid email address format"); } this.emailAddress = emailAddress; } } public class JobApplication { private String applicantEmailAddress; public void setApplicantEmailAddress(String emailAddress) { // Duplicated code if (!emailAddress.matches( "^[\\w.%+-]+@[\\w.-]+\\.[a-zA-Z]{2,}$")) { throw new IllegalArgumentException( "Invalid email address format"); } this.applicantEmailAddress = emailAddress; } }

Después

 public class EmailAddress { // 2. Create an `EmailAddress` class to encapsulate validation rules. private final String value; public EmailAddress(String value) { // The rules are in a single place // And all objects are created valid if (!value.matches("^[\\w.%+-]+@[\\w.-]+\\.[a-zA-Z]{2,}$")) { throw new IllegalArgumentException( "Invalid email address format"); } this.value = value; } } public class Person { private final EmailAddress emailAddress; public Person(EmailAddress emailAddress) { // 1. Identify where email validation logic is duplicated. // 3. Refactor code to use the `Email Address` // class instead of raw strings. // No validation is required this.emailAddress = emailAddress; } } public class JobApplication { private EmailAddress applicantEmailAddress; public JobApplication(EmailAddress applicantEmailAddress) { this.applicantEmailAddress = applicantEmailAddress; } }

Tipo

• [x] Semiautomático

Seguridad

Esta refactorización es segura si reemplaza todas las apariciones de cadenas de correo electrónico sin procesar con la clase 'EmailAddress' y se asegura de que todas las pruebas pasen.

¿Por qué es mejor el código?

Hace que la validación de correo electrónico sea consistente en toda su aplicación.

Como las reglas de validación están centralizadas en un solo lugar, el código resulta más fácil de mantener.

También reduce el riesgo de errores causados por una lógica inconsistente.

En el mundo real, Email Addresses son pequeños objetos que existen y no son cadenas.

El código refactorizado es más cercano al MAPPER del mundo real.

Tenga en cuenta que los nombres de biyección son esenciales. Sería útil crear una EmailAddress , no un Email , ya que el Email debería corresponder al mensaje real.

No permita que los optimizadores prematuros le digan que esta solución tiene una penalización en el rendimiento.

Nunca realizan evaluaciones comparativas reales con datos del mundo real.

Refactorizar con IA

Etiquetas

• Encapsulación

Refactorizaciones relacionadas

Créditos

Imagen de Gerd Altmann en Pixabay

Este artículo es parte de la serie Refactoring.

Cómo mejorar tu código con refactorizaciones sencillas