The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
这是“字符串连接”，这是一个不好的做法：
为什么？有人可能会说它很慢，主要是因为生成的字符串的某些部分被复制了多次。确实，在每个+运算符上，String类会在内存中分配一个新的块，并将其内的所有内容复制过去；然后再连接一个后缀。这是真的，但这不是这里的重点。
实际上，在这种情况下，我认为性能不是一个大问题。此外，有多个实验表明，与其他字符串构建方法相比，连接不是那么慢，有时甚至更快。
有人说，连接的字符串不可本地化，因为在不同的语言中，短语中的文本块可能会以不同的顺序排列。上面的例子不能翻译成俄语，我们希望在“привет”之前放一个名字。我们需要本地化整个代码块，而不仅仅是翻译一个短语。
不过，我的观点不同。我强烈建议避免字符串连接，因为它比其他文本连接方法难以阅读。
让我们看看这些替代方法。我建议使用三种方法（按偏好顺序）：String.format()、Apache StringUtils和Guava Joiner。
还有一个StringBuilder，但我觉得它没有StringUtils那么吸引人。它是一个有用的字符串构建器，但在重视可读性时不是一个合适的替代品或字符串连接工具。
String.format() 是我最喜欢的选项。它使文本短语易于理解和修改。它是一个静态实用方法，类似于 C 语言中的 sprintf()。它允许您使用模式和替代器构建字符串。
当文本较长时，格式化程序的优势变得更加明显。看看这段丑陋的代码：
这个看起来更漂亮，是吧（jSparrow甚至有一个规则来避免这种情况）。
请注意，为了使模式更容易本地化，我使用了参数索引。假设我想将其翻译成希腊语，它将如下所示：
我正在更改模式中的替代顺序，但不改变实际的方法参数列表顺序。
当文本较长（长度超过屏幕宽度）时，我建议您使用Apache commons-lang3中的实用类StringUtils。
需要将额外的JAR依赖项添加到类路径中可能被视为该方法的一个缺点（在Maven Central获取其最新版本）。
Guava Joiner
类似的功能由Google Guava的Joiner提供。
这种方式不如StringUtils方便，因为你总是需要提供一个连接符（字符或放置在文本块之间的字符串）。
同样，在这种情况下需要一个依赖。
是的，在大多数情况下，所有这些方法都比简单的连接方式慢。然而，我坚信“计算机比人便宜”。我的意思是，程序员理解和修改丑陋代码所花费的时间比额外购买一台服务器来提高美观代码运行速度的成本要高得多。
如果你知道其他避免字符串连接的方法，请在下方评论。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 14:47
