从 Play 中生成的 getter 和 setter 中受益！框架
玩吧！框架在运行时为模型类的每个公共字段生成 getter 和 setter。
public class Product {
public String name;
public Integer price;
}
将被转换为
public class Product {
public String name;
public Integer price;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Integer getPrice() {
return price;
}
public void setPrice(Integer price) {
this.price = price;
}
}
手册进一步解释：
然后，当您想要访问属性时，您可以只写：
product.name = "My product";
product.price = 58;
在加载时翻译为：
product.setName("My product");
product.setPrice(58);
... 并警告：
不能直接使用 getter 和 setter 方法来访问属性 如果您依赖自动生成。这些方法生成于 运行时。因此，如果您在编写的代码中引用它们，编译器 将找不到方法并会生成错误。
因为我无法从 Play 之外使用这些 getter 和 setter！项目，我认为生成它们没有任何好处。与所有现代 IDE 的公共字段、重构（封装字段并更改调用者）相比，有什么好处？
The Play! framework generates getters and setters for each public field of a model class at runtime.
public class Product {
public String name;
public Integer price;
}
will be transformed to
public class Product {
public String name;
public Integer price;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Integer getPrice() {
return price;
}
public void setPrice(Integer price) {
this.price = price;
}
}
The manual explains further:
Then when you want to access a property you can just write:
product.name = "My product";
product.price = 58;
Which is translated at load time to:
product.setName("My product");
product.setPrice(58);
... and warns:
You can’t directly use getter and setter methods to access properties
if you rely on automatic generation. These methods are generated at
runtime. So if you reference them in code you write, the compiler
won’t find the methods and will generate an error.
Since I cannot use these getters and setters from outside of the Play! project, I see no benefit in generating them. What is the benefit compared to public fields, refactorings (encapsulate a field and change the callers) of all modern IDEs taken into account?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
简短的回答：豆类需要它们。
更长：Bean 规范要求（除其他外）每个内部字段都有 getter/setter。我不是 100% 确定，但我假设 Hibernate 和 Groovy 模板都需要 Java Bean（POJO Bean，而不是 Java EE！），因此它们会要求 getter/setter。 Play 只是节省您这样做的时间，因此您不必担心样板代码（除非您出于某种原因想要定义自己的 getter/setter，您可以这样做）。
Short answer: Beans require them.
Longer: Beans specification requires (amongst other things) getter/setter for each internal field. I'm not 100% sure, but I assume both Hibernate and Groovy templates expect Java Beans (the POJO Beans, not the Java EE one!), thus they'll ask for getters/setters. Play just saves you time doing that, so you don't have to worry with boiler-plate code (unless you want to define your own getter/setter for some reason, which you can do).
另一个原因是，虽然您不必指定 setter 和 getter，但您仍然可以！
所以，如果你有（根据你的例子）
那很好，并且使你的代码更快并且在我看来更容易阅读。然而，封装 setter 和 getter 是有充分理由的。如果你想在你的product.name改变时添加一些逻辑，你可以指定你自己的setter，但你不必改变上面的代码，因为它会继续在幕后调用setter。
因此，这为您提供了良好封装的灵活性和强大功能，以及直接字段访问的整洁性和可读性。
我认为这是两全其美的。
Another reason,, is although you don't have to specify the setters and getters, you still can!
So, if you have (per your example)
That's fine, and makes your code quicker and in my opinion easier to read. However, there is a good reason for setters and getters for encapsulation. If you wanted to add some logic when your product.name is changed, you can specify your own setter, but you don't have to change the code above, as it will continue to call the setter behind the scenes.
So, this gives you the flexibility and power of good encapsulation, but the neatness and readability of direct field access.
I my opinion this is the best of both worlds.
如果您有私有 getter/setter 方法，那么这将不起作用，因为不可能创建具有相同名称的公共 getter/setter 方法。所以运行时会失败！
If you have a private getter/setter method, then this will not work as it is not possible to create a public getter/setter method with same name. So it will fail at run time!