将电子邮件、电话号码和 ID 表示为 POJO 而不是字符串
Represent email, telephonenumber and id's as POJO's instead of Strings
我有一个典型的商业 Web 应用程序，其中域包含帐户和用户等实体。我的后端是 Java，因此它们由 POJO 表示。在早期的迭代中，那些 POJO 的每个属性都只是字符串。这是有道理的，因为 html 输入是一个字符串，并且数据在数据库中的持久化方式也类似于字符串。
最近，我们一直在努力验证这种输入，我发现如果我为这种属性切换到对象表示法会有所帮助。例如，TelephoneNumber class 包括：
- (int) 国家呼叫代码
- (字符串) 剩下的数字
- (static char) 国家呼叫代码前缀字符（在我们的例子中是 +）
- （静态模式）正则表达式匹配，如果电话号码是有意义的
- 比较和验证电话号码的方法。
这个class有优点也有缺点：
- 不好：在 string/object
之间创建和转换额外的对象
- 好：OOP 和所有关于电话号码的逻辑都捆绑在一个 class（高内聚），
- 很好：每当需要电话号码作为方法或构造函数的参数时，java 的严格类型清楚地表明我们不只是在处理随机字符串。
比较可能混淆的双字符串：
public User(String name, String telephoneNumber)
与干净的 OOP 方式相比：
public User(String name, TelephoneNumber telephoneNumber)
我认为在这种情况下利大于弊。我现在关心的是以下两个属性：
-id（如 b3e99627-9754-4276-a527-0e9fb49d15bb）
-电子邮件地址
这个"objects"实际上只是一个字符串。把它们变成物体似乎有点过分了。特别是 user.getMail.getMailString() 那种方法真的让我很困扰，因为我知道 mailString 是邮件的唯一属性。但是，如果我不把它们变成一个对象，我就失去了一些优势。
所以我的问题是：您如何在 Web 应用程序中处理这些概念？是否有最佳实践或其他问题需要考虑？
对象的最大优点之一是它们可以有方法。例如，所有数据对象（phone 号码、地址、电子邮件等）都可以使用 validate 方法实现相同的接口 IValidatable，这很明显。在这种情况下，将电子邮件包装在一个对象中也是有意义的，因为我们确实想要验证电子邮件。关于 ID - 假设它是由您的应用在内部分配的，您可能不需要包装它。
如果您对所有内容都使用字符串，您实际上是在放弃类型安全，并且您必须 "type check" 在任何 class 或使用字符串的方法中进行验证。不可避免地，此验证代码会重复并使其他 classes 臃肿、混乱，并且可能不一致，因为所有地方的验证都不相同。你永远无法真正确定字符串包含什么，因此调试变得更加困难，维护变得难看，最终浪费了开发人员的大量时间。鉴于现代处理器的强大功能，您不必担心使用大量对象的性能成本，因为牺牲程序员的工作效率（在大多数情况下）不值得。
我发现的另一件事是，字符串变量往往更容易被未来需要制作 "quick fix" 的程序员滥用，因此他们会在需要的地方设置新值以方便使用，而不是扩展类型并弄清楚发生了什么。
我的建议是尽可能使用有意义的类型。
最大化打字的好处导致了 "tiny types" 的想法，您可以在这里阅读：http://darrenhobbs.com/2007/04/11/tiny-types/
本质上它意味着你让 classes 来代表 一切。在您使用 User class 的示例中，这意味着您还需要使用 Name class 来表示名称。在那个 class 里面，你可能还有两个 class，FirstName 和 LastName。这增加了代码的清晰度，并最大限度地减少了编译器阻止您犯的逻辑错误的数量。在大多数情况下，您永远不会在需要姓氏的地方使用名字，反之亦然。
我有一个典型的商业 Web 应用程序，其中域包含帐户和用户等实体。我的后端是 Java，因此它们由 POJO 表示。在早期的迭代中，那些 POJO 的每个属性都只是字符串。这是有道理的，因为 html 输入是一个字符串，并且数据在数据库中的持久化方式也类似于字符串。
最近，我们一直在努力验证这种输入，我发现如果我为这种属性切换到对象表示法会有所帮助。例如，TelephoneNumber class 包括：
- (int) 国家呼叫代码
- (字符串) 剩下的数字
- (static char) 国家呼叫代码前缀字符（在我们的例子中是 +）
- （静态模式）正则表达式匹配，如果电话号码是有意义的
- 比较和验证电话号码的方法。
这个class有优点也有缺点：
- 不好：在 string/object 之间创建和转换额外的对象
- 好：OOP 和所有关于电话号码的逻辑都捆绑在一个 class（高内聚），
- 很好：每当需要电话号码作为方法或构造函数的参数时，java 的严格类型清楚地表明我们不只是在处理随机字符串。
比较可能混淆的双字符串：
public User(String name, String telephoneNumber)
与干净的 OOP 方式相比：
public User(String name, TelephoneNumber telephoneNumber)
我认为在这种情况下利大于弊。我现在关心的是以下两个属性：
-id（如 b3e99627-9754-4276-a527-0e9fb49d15bb） -电子邮件地址
这个"objects"实际上只是一个字符串。把它们变成物体似乎有点过分了。特别是 user.getMail.getMailString() 那种方法真的让我很困扰，因为我知道 mailString 是邮件的唯一属性。但是，如果我不把它们变成一个对象，我就失去了一些优势。
所以我的问题是：您如何在 Web 应用程序中处理这些概念？是否有最佳实践或其他问题需要考虑？
对象的最大优点之一是它们可以有方法。例如，所有数据对象（phone 号码、地址、电子邮件等）都可以使用 validate 方法实现相同的接口 IValidatable，这很明显。在这种情况下，将电子邮件包装在一个对象中也是有意义的，因为我们确实想要验证电子邮件。关于 ID - 假设它是由您的应用在内部分配的，您可能不需要包装它。
如果您对所有内容都使用字符串，您实际上是在放弃类型安全，并且您必须 "type check" 在任何 class 或使用字符串的方法中进行验证。不可避免地，此验证代码会重复并使其他 classes 臃肿、混乱，并且可能不一致，因为所有地方的验证都不相同。你永远无法真正确定字符串包含什么，因此调试变得更加困难，维护变得难看，最终浪费了开发人员的大量时间。鉴于现代处理器的强大功能，您不必担心使用大量对象的性能成本，因为牺牲程序员的工作效率（在大多数情况下）不值得。
我发现的另一件事是，字符串变量往往更容易被未来需要制作 "quick fix" 的程序员滥用，因此他们会在需要的地方设置新值以方便使用，而不是扩展类型并弄清楚发生了什么。
我的建议是尽可能使用有意义的类型。
最大化打字的好处导致了 "tiny types" 的想法，您可以在这里阅读：http://darrenhobbs.com/2007/04/11/tiny-types/
本质上它意味着你让 classes 来代表 一切。在您使用 User class 的示例中，这意味着您还需要使用 Name class 来表示名称。在那个 class 里面，你可能还有两个 class，FirstName 和 LastName。这增加了代码的清晰度，并最大限度地减少了编译器阻止您犯的逻辑错误的数量。在大多数情况下，您永远不会在需要姓氏的地方使用名字，反之亦然。