一度だけ言ってください
TL;DR: 重複した電子メール検証を避けてください。
対処された問題
- 複数の場所で電子メール検証ロジックが繰り返されます。
- 検証ルールが矛盾するリスク。
- 一対一変換違反
- 原始的な強迫観念
- 時期尚早な最適化
関連するコードスメル
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
手順
電子メール検証ロジックが重複している場所を特定します。
検証ルールをカプセル化する
Email Addressクラスを作成します。
生の文字列の代わりに
Email Addressクラスを使用するようにコードをリファクタリングします。
サンプルコード
前に
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; } }後
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; } }タイプ
- [x]セミオートマチック
安全性
このリファクタリングは、生の電子メール文字列のすべての出現を 'EmailAddress' クラスに置き換え、すべてのテストに合格することを保証すれば安全です。
なぜコードの方が優れているのでしょうか?
アプリケーション全体で電子メールの検証を一貫させます。
検証ルールが 1 か所に集中しているため、コードの保守が容易になります。
また、一貫性のないロジックによって発生するバグのリスクも軽減されます。
現実の世界では、 Email Addresses存在する小さなオブジェクトであり、文字列ではありません。
リファクタリングされたコードは、実際のMAPPERに近くなります。
バイジェクション名が必須であることに注意してください。 Email は実際のメッセージにマップされる必要があるため、 EmailではなくEmailAddressを作成すると役立ちます。
早すぎる最適化者から、このソリューションにはパフォーマンスの低下があると言われないようにしてください。
彼らは現実世界のデータを使って実際のベンチマークを行うことは決してありません。
AIによるリファクタリング
適切な指示がなければ | 具体的な指示 |
|---|---|
タグ
- カプセル化
関連するリファクタリング
クレジット
Gerd AltmannによるPixabayの画像
この記事はリファクタリング シリーズの一部です。
