问题描述
我无意中听到两位同事争论是否要创建一个新的数据模型类，它只包含一个字符串字段，一个setter和一个getter。 然后程序将创建该类的一些对象并将它们放入数组列表中。 存储它们的人认为应该有一种新类型，而获取数据的人说，没有点可以解决所有这些麻烦，而你可以简单地存储字符串。
我个人更喜欢创建一个新类型，所以我们知道数组列表中存储了什么，但我没有强有力的论据来说服“获取”数据的人。 你呢？
莎拉
1楼
...一个新的数据模型类，它只包含一个字符串字段，一个setter和一个getter。
如果它只是一个getter，那么通常不能说String或自定义类是否更好。 这取决于：
- 与其他数据模型的一致性，
- 期待您是否可能想要更改表示，
- 预测在创建实例时是否需要实现验证，添加辅助方法等，
- 对内存使用或持久性的影响（如果它们甚至相关）。
（就个人而言，我倾向于默认使用普通的字符串，并且仅使用自定义类，例如，我知道可能需要未来的表示更改/细化。在大多数情况下，它不是以后将String更改为自定义类的巨大问题......如果需要的话。）
然而，有人建议成为该领域的制定者，这一事实将会发生重大变化。 该类的实例将是可变的，而String的实例则不是。 一方面，这可能是有用的; 例如，你真正需要可变性的地方。 另一方面，可变性会使该类在某些情况下使用有些风险; 例如在集合中和作为地图中的键。 在其他情况下，您可能需要复制实例。 （对于不可变的包装类或裸String，这是不必要的。）
（简单的答案是摆脱二传手，除非你真的需要它。）
还有一个问题是，对于String和自定义包装器， equals的语义会有所不同。
因此，您可能需要重写equals和hashCode以在自定义包装器案例中获得更直观的语义。
（这与setter的问题有关，并且在集合中使用了类。）
2楼
如果它与数据模型的其余部分相匹配，请将其包装在类中。
- 它为您提供了字符串的标签，以便您可以在运行时告诉它代表什么。
- 它使您可以更轻松地获取实体并添加其他字段和行为。 （可能会发生这种情况>）
也就是说，关键是它是否与您数据模型的其余设计相匹配 ......与您已有的一致。
3楼
与mschaef的回答相对应：
如果它与数据模型的其余部分相匹配，请将其保留为字符串。 （看看开口听起来如此重要，即使我用一句基本上说我们不知道答案的句子来调整它？）
- 如果您需要标签说明它是什么，请添加评论。 成本=一行，总计。 哎呀，就此而言，你需要一行（或三行）来评论你的新课程，那么什么是课堂宣言？
- 如果以后需要增加额外的字段，你可以重构它即可 。 你无法设计所有东西，如果你尝试过，你最终会陷入可怕的混乱。
正如 ，“代码库中最糟糕的事情就是大小”。 添加一个类声明，一个getter，一个setter，现在调用来自触摸它的所有地方的那些，并且你已经为代码添加了大小 。
4楼
我不同意其他答案：
这取决于以后是否有任何向行为添加行为的可能性[ ]
不，它没有。 ...
从来没有伤害过未来的设计[ ]
没错，但这里不相关......
就个人而言，我倾向于默认使用普通的字符串[ ]
但这不是意见问题。 这是设计决策的问题：
您存储的实体在逻辑上是一个字符串，一段文本？ 如果是，则存储字符串（忽略setter问题）。
如果没有 -那么不存储的字符串。 该数据可能存储为字符串是一个实现细节 ，它不应该反映在您的代码中。
对于第二点，您是否可能希望稍后添加行为无关紧要。 重要的是，在强类型语言中，数据类型应该描述逻辑实体。 如果您处理的不是文本（但可能由文本表示，可能包含文本...），则使用内部存储所述文本的类。 不要直接存储文本。
这是抽象和强类型的全部要点：让类型代表代码的语义。
最后：
正如Yegge所说，“代码库中最糟糕的事情就是大小”。 [ ]
嗯，这太讽刺了。 你有没有读过Steve Yegge的博文？ 我没有，他们太长了 。
5楼
这取决于以后是否有可能向该类型添加行为。 即使吸气剂和制定者现在微不足道，如果他们真的有机会在以后做某事，那么这种类型也是有意义的。 否则，清除变量名称就足够了。
6楼
在讨论是否将它包装在一个类中的时间里，它可以被包装并完成。 永远不会伤害到面向未来的设计，特别是当它只需要很少的努力时。
7楼
我认为没有理由将String包装在一个类中。 讨论背后的基本观念是，时间的需要是一个String对象。 如果它稍后得到增强，那么重新进行重构。 为什么在未来的证明名称中添加不必要的代码。
8楼
将它包装在类中为您提供了更多的类型安全性 - 在您的模型中，您只能使用包装类的实例，并且在将包含不同内容的字符串放入模型中时，您不会轻易犯错。
但是，它确实会增加代码的开销，额外的复杂性和冗长。