恒等标志（和其他）

我目前正在重构从另一个开发者继承的代码库。在几个类中，我发现包含符号=，？的常量和&（和其他人）。它们用于构建URL，如下所示：恒等标志（和其他）

class SomeClass { 
    private static final String EQUALS = "="; 
    private static final String AMPERSAND = "&"; 
    private static final String QUESTION_MARK = "?"; 
    private static final String FORWARD_SLASH = "/"; 
    // ... 

    public String getSomeURL() { 
     return ProjectConstants.BASE_URL + entityName + FORWARD_SLASH + 
      anotherName + QUESTION_MARK + parameterName + EQUALS + parameterValue; 
    } 
}

我看不出这样做的好处。这种风格的原因是什么，而不是只写variable + '/' + variable + "?parameterName=" + parameterValue？

来源

2016-12-14 marstato

我认为不会有任何深技术原因在这里

唯一小件事我看到：他们让错别字，如“==”不太可能发生，平等相待+ EQUALS显然更明显现货。

另一方面，这在现实中并不重要;因为实际上你会打电话帮手方法来建立这些网址。所以，一旦你找到了帮手，就很少有机会在“生成”内容中输入错别字。

但即使如此，我不会使用字符串常量，但字符值。

来源

2016-12-14 14:18:10 GhostCat

错字预防实际上是一个很好的点。虽然，我同意你的看法：辅助方法应该照顾到这一点。 – marstato

这些常量很有用，但名字很差。如果他们在URL用于建筑，它们应该被命名为这样的：

private static final String PARAMETER_ASSIGNMENT = "="; 
private static final String PARAMETER_SEPARATOR = "&"; 
private static final String QUERY_INTRODUCER = "?"; 
private static final String PATH_SEPARATOR = "/";

这样一来，他们的名字会参考他们的语义（他们应该），而不是他们的内容（全点是摘要远离内容！）。

的getSomeURL()的代码就更加直接信号，它确实：

public String getSomeURL() { 
    return ProjectConstants.BASE_URL + entityName + 
      PATH_SEPARATOR + anotherName + 
      QUERY_INTRODUCER + 
       parameterName + PARAMETER_ASSIGNMENT + parameterValue; 
}

来源

2016-12-14 14:18:40 Angew

这是更多的语义，是的。但是，阅读它比单纯使用内嵌字符/字符串还要困难得多。 – marstato

@marstato问题是，网址是如此众所周知以至于常量的值不可能改变。但是，如果您发现自己调整该类以提供网址以外的格式的数据，则其优势将变得明显。整个观点是：只要你给它一个更好的名字而不仅仅是它的价值，就应该命名一个常数。在这种情况下，你*可以*。 – Angew

这是一个有效的原因。但它并不能掩盖可读性的损失，尽管如此。 – marstato

恒等标志（和其他）

回答

相关问题