Question

我维护的库使用各种语义含义的字符串。例如，一个字符串是发票代码，另一个是引用代码。根据这些类型，存在这些语义类型和查找方法的文档。为了区分这些值的语义，我开始创建名为CharSequence，InvoiceCode等QuotationCode的实现。

我使用Boost.Units作为灵感。在C ++中使用物理方程时，绝对没有办法解决它。使用普通double将导致未知单位非常快。我担心在我的库中到处使用String时会发生同样的情况。

现在我的大学抱怨说，在调用我的库之前从String转换为语义类型过于繁琐，而不是在想要使用结果时回到String。 / p>

在我看来，我的大学应该在他们的代码中使用适当的类型。

所以最后问题归结为：在Java中使用语义类型而不是String推荐和/或常见做法吗？

Answer 1

C ++有两个关键特性，可以更容易地使用用户定义的语义类型 - 转换运算符和运算符重载。 Java没有这两者中的任何一个，使你对语义类型的推动成为一场艰苦的战斗。

使用CharSequence界面可以让您的库用户更容易在从库中获取数据时避免转换为字符串。但是，将所有这些InvoiceCode和QuotationCode对象传递给您需要在来电者方面做更多的工作。

如果用户总是这样做

source.yourMethod(new QuotationCode(theirObject.quotationCodeString))

那么你是对的，他们应该用String quotationCodeString替换对象中的QuotationCode quotationCode，并使其易于使用。

另一方面，如果他们经常这样做

source.yourMethod(new QuotationCode("xyz-code"))

然后定义知名报价代码的来源是个好主意，让您的用户改为编写：

source.yourMethod(QuotationCode.XyzCode)

其中XyzCode是一个众所周知的引用代码，您的用户将其硬编码为String。

Answer 2

没有自己的域类型。

由于这些类型的数据通常存储在数据库中，并且实际上在数据库中得到了最佳处理，因此最终自己的域值类可能会产生反作用。 <{1}}或某些DSL中的声明性业务规则也受到阻碍。

这取决于这些数据存储库的用法：像jOOQL这样的DSL，或者速度或JPA。后者执行对象/关系映射，ID域通常由java类替换。

对于用户定义的代码，实际上不需要java类型：您不希望逐个处理硬编码值。那些应该是声明性的。例如，基于发票类别和合同的报表选择不应由嵌套的ifs / switches完成。

Answer 3

对于你所描述的，自然的“语义类型”是一个枚举。枚举类型T应覆盖'T toString（）'并实现'static T fromString（String）'（或者只使用'valueOf（）'），这使得同事可以轻松使用，因为类型可以自己进行转换

您不需要运算符重载，这会引入比解决的问题更多的问题。你有转换方法，它完全不需要转换操作符，所以与C ++的比较是似是而非。