Heim >Web-Frontend >js-Tutorial >Refactoring – E-Mail-Adressen neu definieren

Refactoring – E-Mail-Adressen neu definieren

Barbara Streisand
Barbara StreisandOriginal
2024-12-25 16:50:15853Durchsuche

Sag es einmal und nur einmal

TL;DR: Vermeiden Sie doppelte E-Mail-Validierungen.

Behandelte Probleme

  • Wiederholte E-Mail-Validierungslogik an mehreren Stellen.
  • Risiko inkonsistenter Validierungsregeln.
  • Schwierig, Validierungsregeln einzuhalten.
  • Bijektionsverletzung
  • Primitive Besessenheit
  • Vorzeitige Optimierung

Verwandte Code-Smells

Refactoring  - Reify Email Addresses

Code Smell 46 – Wiederholter Code

Maxi Contieri ・ 8. Dezember 2020

#oop #codenewbie #tutorial #webdev
Refactoring  - Reify Email Addresses

Code Smell 122 – Primitive Obsession

Maxi Contieri ・ 17. März 22

#oop #webdev #tutorial #Anfänger
Refactoring  - Reify Email Addresses

Code Smell 66 – Schrotflintenchirurgie

Maxi Contieri ・ 5. April 21

#codenewbie #tutorial #oop #webdev
Refactoring  - Reify Email Addresses

Code Smell 177 – Fehlende kleine Objekte

Maxi Contieri ・ 5. November 22

#webdev #javascript #Anfänger #Programmierung
Refactoring  - Reify Email Addresses

Code Smell 20 – Vorzeitige Optimierung

Maxi Contieri ・ 8. November 2020

#oop #Entwicklung #Codierung #codesmell

Schritte

  1. Identifizieren Sie, wo die E-Mail-Validierungslogik dupliziert wird.
  2. Erstellen Sie eine E-Mail-Adressklasse, um Validierungsregeln zu kapseln.
  3. Code umgestalten, um die Klasse „E-Mail-Adresse“ anstelle von Rohzeichenfolgen zu verwenden.

Beispielcode

Vor

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

Nach

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

Typ

[X] Halbautomatisch

Sicherheit

Dieses Refactoring ist sicher, wenn Sie alle Vorkommen von Roh-E-Mail-Strings durch die Klasse „EmailAddress“ ersetzen und sicherstellen, dass alle Tests bestanden werden.

Warum ist der Kodex besser?

Sie sorgen für eine konsistente E-Mail-Validierung in Ihrer gesamten Anwendung.

Da die Validierungsregeln an einem Ort zentralisiert sind, ist der Code einfacher zu warten.

Sie verringern außerdem das Risiko von Fehlern, die durch inkonsistente Logik verursacht werden.

In der realen Welt sind E-Mail-Adressen kleine existierende Objekte und keine Zeichenfolgen.

Der überarbeitete Code kommt dem realen MAPPER näher

Beachten Sie, dass Bijektionsnamen unerlässlich sind. Es wäre hilfreich, eine „EmailAddress“ und keine „E-Mail“ zu erstellen, da die E-Mail der eigentlichen Nachricht zugeordnet werden sollte.

Lassen Sie sich von vorzeitigen Optimierern nicht sagen, dass dies zu Leistungseinbußen führt.

Sie führen niemals tatsächliche Benchmarks mit realen Daten durch.

Refactoring mit KI

Without Proper Instructions With Specific Instructions
ChatGPT ChatGPT
Claude Claude
Perplexity Perplexity
Copilot Copilot
Gemini Gemini

Schlagworte

  • Kapselung

Verwandte Refactorings

Refactoring  - Reify Email Addresses

Refactoring 007 – Klasse extrahieren

Maxi Contieri ・ 4. Juli '22

#webdev #Anfänger #javascript #tutorial
Refactoring  - Reify Email Addresses

Refactoring 012 – Assoziative Arrays reifizieren

Maxi Contieri ・ 19. November 2023

#webdev #Programmierung #Anfänger #php
Refactoring  - Reify Email Addresses

Refactoring 002 – Extraktionsmethode

Maxi Contieri ・ 25. November 21

#Refactoring #oop #webdev #codenewbie

Credits

Bild von Gerd Altmann auf Pixabay


Dieser Artikel ist Teil der Refactoring-Reihe.

Refactoring  - Reify Email Addresses

So verbessern Sie Ihren Code mit einfachen Refactorings

Maxi Contieri ・ 24. Okt. 22

#webdev #Anfänger #Programmierung #tutorial

Das obige ist der detaillierte Inhalt vonRefactoring – E-Mail-Adressen neu definieren. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn