假设我有一个代表一个人的对象,使用该人的电子邮件地址的getter和setter方法.setter方法定义可能如下所示:
setEmailAddress(String emailAddress)
{
this.emailAddress = emailAddress;
}
Run Code Online (Sandbox Code Playgroud)
person.setEmailAddress(0)然后,调用会产生类型错误,但调用person.setEmailAddress("asdf")不会 - 尽管"asdf"绝不是有效的电子邮件地址.
根据我的经验,所谓的字符串几乎不是任意字符序列,对长度或格式没有限制.我想到了URI - 街道地址和电话号码一样,名字也一样......你明白了.然而,这些数据类型通常存储为"只是字符串".
回到我的个人目标,假设我修改setEmailAddress(),像这样
setEmailAddress(EmailAddress emailAddress)
// ...
Run Code Online (Sandbox Code Playgroud)
where EmailAddress是一个类...其构造函数采用电子邮件地址的字符串表示形式.我有什么收获吗?
好的,所以电子邮件地址是一个不好的例子.如何将URI类作为构造函数参数的URI字符串表示,并提供管理该URI的方法 - 设置路径,获取查询参数等.源字符串的有效性变得很重要.
所以我问你们所有人,你们如何处理具有结构的字符串?您如何在界面中明确您的结构期望?
谢谢.
欢迎来到编程世界!
我不认为你的问题是你犯错误的征兆。相反,它是一个基本问题,在整个编程世界中以多种形式出现。具有某种结构和含义的字符串在应用程序的不同子系统之间传递,每个子系统只能进行大量解析和验证。
例如,验证电子邮件地址的问题就非常棘手。例如,人们提供的接受电子邮件地址的正则表达式通常要么“太紧”(不接受所有内容),要么“太松”(接受非法内容)。例如,第一个谷歌搜索“正则表达式“电子邮件地址””:
我收到最多反馈的正则表达式(更不用说“错误”报告了)就是您可以在本网站主页上找到的正则表达式:\b[A-Z0-9._%+-]+@[A -Z0-9.-]+.[AZ]{2,4}\b 使用 RegexBuddy 分析此正则表达式。我声称这个正则表达式可以匹配任何电子邮件地址。我收到的大多数反馈都通过显示该正则表达式不匹配的一个电子邮件地址来反驳这一说法。
事实上,什么是有效的电子邮件地址或什么不是有效的电子邮件地址是一个复杂的问题,给定的程序可能想要也可能不想解决这个问题。URL 的问题更加严重,特别是考虑到恶意 URL 的可能性。
理想情况下,您可以拥有一个库或系统调用来解决此类问题,而不是自己做任何事情(Microsoft Windows 调用自定义对话框以允许用户选择或创建文件,因为验证文件名是另一个棘手的问题) 。但您也不能总是指望为给定的“有意义的字符串”提供适当的系统调用。
我想说,对于带有结构的字符串问题,没有通用的解决方案。相反,这是在设计应用程序时出现的一个基本问题。在收集应用程序需求的过程中,您应该确定应用程序将接收哪些数据以及这些数据对应用程序的意义有多大。这就是事情变得棘手的地方,因为您可能会注意到该应用程序可能会以您的老板或客户可能没有想到的方式发展 - 或者该应用程序实际上可能会以您没有想到的方式发展。因此,应用程序需要比看起来最低限度更灵活一点,但只是一点点。它也不应该太灵活以至于陷入困境。
现在,如果您决定需要验证/解释给定字符串等,则将该字符串放入对象或散列中可能是一个好方法 - 这是我知道的确保界面清晰的一种方法。但棘手的事情是决定你需要多少验证或解释。
因此,做出这些决定是一门艺术——这里没有教条的答案。
| 归档时间: |
|
| 查看次数: |
311 次 |
| 最近记录: |