Sig det én gang og kun én gang

TL;DR: Undgå duplikerede e-mail-valideringer.

Problemer rettet

• Gentagen e-mail-valideringslogik flere steder.
• Risiko for inkonsistente valideringsregler.
• Overtrædelse af Bijektion
• Primitiv besættelse
• For tidlig optimering

Relateret kode lugte

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

Kode Smell 20 - For tidlig optimering

Trin

1. Identificer, hvor e-mailvalideringslogikken er duplikeret.

   
   

2. Opret en Email Address for at indkapsle valideringsregler.

   
   

3. Refaktorer kode for at bruge Email Address i stedet for rå strenge.

Eksempel kode

Før

 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; } }

Efter

 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; } }

Type

• [x] Halvautomatisk

Sikkerhed

Denne refactoring er sikker, hvis du erstatter alle forekomster af rå e-mail-strenge med klassen 'EmailAddress' og sikrer, at alle tests består.

Hvorfor er koden bedre?

Du gør e-mailvalidering konsistent på tværs af din ansøgning.

Da valideringsregler er centraliseret ét sted, bliver koden lettere at vedligeholde.

Du reducerer også risikoen for fejl forårsaget af inkonsekvent logik.

I den virkelige verden er Email Addresses små objekter , der eksisterer og ikke er strenge.

Den refaktorerede kode er tættere på den virkelige MAPPER .

Bemærk, at bijektionsnavne er vigtige. Det ville hjælpe at oprette en EmailAddress , ikke en Email , da e-mailen skal knyttes til den faktiske besked.

Lad ikke Premature Optimizers fortælle dig, at denne løsning har en præstationsstraf.

De laver aldrig egentlige benchmarks med data fra den virkelige verden.

Refaktor med AI

Tags

• Indkapsling

Relaterede Refactorings

Kreditter

Billede af Gerd Altmann på Pixabay

Denne artikel er en del af Refactoring-serien.

Sådan forbedrer du din kode med nemme refactorings