代表電子郵件，電話號碼和編號爲POJO而不是字符串

Question

我有一個典型的商業Web應用程序，其中的域包含像賬戶和用戶這樣的實體。我的後端是Java，所以它們由POJO代表。在早期迭代期間，這些POJO的每個屬性都只是字符串。這是有道理的，因爲html輸入是一個字符串，並且數據在數據庫中的保存方式也類似於字符串。

最近，我們一直致力於驗證這種輸入，我發現它有助於切換到這種屬性的對象表示法。例如，TelephoneNumber類包括：

• （int）的國碼
• （串）數量的剩餘
• （靜態字符）的前綴國碼（在我們的情況下，這個字符是+）
• （靜態模式）正則表達式匹配，如果phonenumber是有道理的
• 方法來比較和驗證電話號碼。

此類具有優點和缺點：

• 不好：其他對象的創建和串/對象之間的轉換
• 良好：OOP和關於電話號碼在一類捆綁所有邏輯（高凝聚力），
• 好：無論何時需要一個電話號碼作爲方法或構造函數的參數，java的嚴格打字使得它非常清晰，我們不僅僅處理隨機字符串。

比較可能的混亂雙串：

public User(String name, String telephoneNumber) 

VS乾淨的OOP方式：

public User(String name, TelephoneNumber telephoneNumber) 

我認爲在這種情況下的優點outweight的disadvantges。我現在擔心的是以下兩個屬性：

-id的（如b3e99627-9754-4276-a527-0e9fb49d15bb） -e-mailadresses

這個 「對象」 是真的只是一個字符串。把它們變成物體看起來有點矯枉過正。特別是user.getMail.getMailString()類方法真的打擾我，因爲我知道mailString是郵件的唯一屬性。但是，如果我不把它們變成一個對象，我會失去一些優點。

所以我的問題是：你如何處理這個概念在Web應用程序？需要考慮最佳實踐或其他問題嗎？

Answer 1

如果您使用字符串的任何事情都基本放棄了類型安全性，並且您必須在使用該字符串的任何類或方法中進行「驗證」類型的驗證。不可避免地，這個驗證代碼會被複制，並使其他類變得臃腫，混亂，並且可能不一致，因爲驗證在所有地方都不相同。你永遠不能確定字符串是什麼，所以調試變得更加困難，維護變得很難看，並最終浪費了大量的開發者時間。鑑於現代處理器的強大功能，您不必擔心使用大量對象的性能成本，因爲它不值得犧牲程序員的生產力（在大多數情況下）。

我發現的另一件事是字符串變量往往更容易被未來需要做「快速修復」的程序員濫用，所以他們會爲了方便而設置新的值，只是在他們需要它們的地方而已擴展類型並明確發生了什麼。

我的建議是在任何可能的地方使用有意義的類型。

打字最大化的利益造成「微小的類型」，你可以讀到這裏的想法：http://darrenhobbs.com/2007/04/11/tiny-types/

本質上，它意味着你做的類來表示一切。在你的User類的例子中，這意味着你也可以使用Name類來表示名稱。在該課程中，您可能還有兩門課FirstName和LastName。這增加了代碼的清晰度，並最大化了編譯器阻止您製作的邏輯錯誤的數量。在大多數情況下，你永遠不會在你想要姓氏的地方使用名字，反之亦然。

Answer 2

對象的最大優點之一是它們可以有方法。例如，您的所有數據對象（電話號碼，地址，電子郵件等）都可以使用與validate方法相同的接口，這很明顯。在這種情況下，將電子郵件包裹在對象中也是有意義的，因爲我們確實想要驗證電子郵件。關於ID - 假設它由您的應用程序內部分配，您可能不需要包裝它。