在我多年的编程生涯中，我经常制作简单地将一些变量与它们的 setter 和 getter 组合在一起的类。我已经看到根据使用它们的上下文将这些类型的对象称为值对象、域对象或模型对象。最适合通用用法的术语似乎是数据传输对象 (DTO)。这描述了一个只包含访问器和修改器的 POJO。
我刚刚编写了一个这样的对象，其中包含大约 50 个用于在图表上设置主题参数的字段。现在我想知道是否应该将这些字段声明为公共字段，而不是生成一百个 getter 和 setter。这样做违背了我的编程直觉告诉我的一切，但我不能否认它会大大提高我的代码的易读性并减少类中样板代码的数量。
我可以看到不使用公共字段的唯一原因是如果我需要对这些字段执行任何类型的验证。如果我们假设类型验证足以满足我的目的，那么在这种情况下使用公共字段是否可以接受面向对象设计的突破？公共 DTO 会在大批量操作中表现更好吗？
大多数程序员会默认使用带有 getter/setter 的私有字段而不考虑它。但就像任何货物崇拜一样，最好做出有意识的决定。
使用 getter/setter 组合而不是公共字段的主要原因是您可以更改定义。因此，如果您的 DTO 是组件之间接口的一部分，最好使用 getter。如果更改内部工作原理，则可以调整 getter 以模仿旧行为并保持兼容性。
另一个原因是您可以设置只读字段。通常对于 DTO，只读和不可变是一个不错的选择。
第三个原因可能是您的 DTO 需要是一个 javabean，因为您打算在某些需要它的工具中使用它。
如果这些属性都不适合您，那么没有理由不使用公共字段。
不过，不要期望有太大的性能差异:)
我认为拥有具有公共属性的“设置”或“主题”或“样式”类并不是非常糟糕的做法。
如果您想在设置时间进行任何复杂的计算或检查值，则具有重构工具的现代 IDE 可以轻松地将属性提升为 getter/setter。
通常，在您的“setTheme”或使用这些设置类的任何函数中，是进行验证的好地方。
在设置这样的设置时，通常适合进行深度复制对象，而不是保留对可变类的引用。
DataStructure 和 Object 是有区别的。
数据结构应该暴露其内在而不是行为。
一个物体不应该暴露它的内在，但它应该暴露它的行为，这也被称为得墨忒耳法则
因此，DTO 基本上是数据结构。他们应该只公开他们的数据，他们不需要 Getter 和 Setter。验证是一种行为，它不应该是 DTO 的一部分。它必须有一个不同的对象，即验证对象。
灵感来自Robert C. Martin（鲍勃叔叔）的Clean Code