使用light-jprotobuf生成的proto没有字段

[2623460880]

我根据文档中的light-jprotobuf 生成示例 生成了proto，结果如下

但是我的类文件是这样的

[渔民小镇]

请提供一个可复现的 demo

[2623460880]

请提供一个可复现的演示

你好，我已经发现问题了,字段使用private修饰的时候就会出现这个问题,被public修饰的字段就会被生成出来,是不是转换的过程中使用的是反射，获取属性的时候只获取了public的属性

[渔民小镇]

有可能，时间太久；这部分有点小忘；

https://www.yuque.com/iohao/game/keyrxn#pQhjD

协议文件定义

在简单介绍中，我们知道了如何自定义一个协议文件。这个协议文件作为我们的业务载体描述。这个协议是纯java代码编写的，使用的是 jprotobuf，jprotobuf 是对 google protobuf 的简化使用，性能同等。

可以把这理解成DTO、POJO、业务数据载体等，其主要目的是用于业务数据的传输；

/** 请求 */
@ToString
@ProtobufClass
@FieldDefaults(level = AccessLevel.PUBLIC)
public class Hello {
    String name;
    int level;
}

在协议文件中，不建议做 setter、getter 内的逻辑加工，只定义业务属性。所以推荐使用 lombok 将属性的权限统一设置为 public，并且加上 ToString 注解，这样在开发阶段可以得到很好的打印输出信息。

为什么在协议文件中只推荐定义属性呢？

因为数据载体只做数据的运输，符合其意义。假设我们给数据载体赋予其他职责，如添加 setter、getter 并在里面做一些逻辑，或者添加一些其他的方法逻辑，会使项目维护成本提高。

这将会导致开发人员至少需要关注两个地方，一个是需要打开协议看里面有没有添加额外的逻辑，一个是需要查找相关的业务逻辑代码，比如在 xxxService 里面做的逻辑。

因为开发人员的开发年限不一，有的会在协议文件里面做逻辑，有的则会在 xxxService 里面做逻辑。为了防止这种情况的出现，这里建议协议文件里面只做属性的定义。这样就可以提前避免这些问题，由于协议文件里面不做任何的逻辑了，所以当数据出现问题时，我们查找问题的范围也就缩小了。

小结
简单的说，正常情况下推荐使用 Hello.name = "xxx" 的编码方式，如果使用 Hello.setName("xxx") 通常表示内部会对当前对象的其他属性造成改变。

另外这种方式也可以使得代码更清晰，避免了大量 getXXX() 和 setXXX() 的代码；