在什么场景下会用到封装？
我想知道你在什么场景下使用封装。此问题的目的是协作。因此，当主题是封装时，请随意分享您自己的经验。
一些场景：
计算属性
public class Order {
private List<ListItem> listItems = new ArrayList<ListItem>();
public double getTotal() {
double total = 0;
for(ListItem listItem: listItems)
total += listItem.getQuantity() * listItem.getPropduct().getPrice();
return total;
}
}
自验证域对象
public class Person {
private String name;
public void setName(String name) {
if(StringUtils.isBlank(name)) {
throw new NotEmptyException("name", name);
}
this.name = name;
}
}
利用其他类型的类来实现某些特殊行为
public class Person {
private MutableInt id = new MutableInt();
/**
* Integer itself is immutable
*/
public Integer getId() {
retur id.intValue();
}
}
转换
public class Person {
public String enabled;
public boolean isEnabled() {
return "Y".equals(enabled);
}
}
I would like to know in what scenarios you use encapsulation. The purpose of this question is collaborative. So feel free to share your own experience when the subject is encapsulation.
Some scenarios:
Calculated property
public class Order {
private List<ListItem> listItems = new ArrayList<ListItem>();
public double getTotal() {
double total = 0;
for(ListItem listItem: listItems)
total += listItem.getQuantity() * listItem.getPropduct().getPrice();
return total;
}
}
Self-validating domain objects
public class Person {
private String name;
public void setName(String name) {
if(StringUtils.isBlank(name)) {
throw new NotEmptyException("name", name);
}
this.name = name;
}
}
Makes use of other kind of classes for some special behavior
public class Person {
private MutableInt id = new MutableInt();
/**
* Integer itself is immutable
*/
public Integer getId() {
retur id.intValue();
}
}
Conversion
public class Person {
public String enabled;
public boolean isEnabled() {
return "Y".equals(enabled);
}
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当存在用户可能搞砸的场景时，我会进行封装。例如，如果我正在编写一个显示文本的类，我不会封装我持有字符串的事实，因为任何字符串都可以有效显示。
封装的存在是为了验证和接口更改。如果您有一个不需要验证的参数（并且接口定义良好），则封装它是没有意义的，特别是如果您使用的语言没有任何内置工具，例如 Java（工具例如，C# 属性）。
封装是一个像其他工具一样的工具，不应该仅仅因为可以就将其扔得到处都是。
I encapsulate when there is a scenario in which the user can screw it up. e.g., if I was writing a class that displayed text, I would not encapsulate the fact that I hold a string, because any string is valid for display.
Encapsulation exists for validation and interface change. If you have a parameter that needs no validation (and the interface is well-defined), there's no point in encapsulating it, especially if you use a language which doesn't come with any in-built tools for it, like Java (tools being, for example, C# properties).
Encapsulation is a tool like any other and should not be thrown all over everywhere just because you can.
简而言之，我更喜欢在我设计/实现的所有非私有 API 中使用强封装。
习惯上不使用强封装的唯一情况是使用 private 嵌套类，这些类（并且需要）只不过是仿制品
struct声明。我的理由是，私有类通过嵌套和私有而得到了充分的封装。如果这样做有令人信服的性能原因，我也准备放松封装（稍微）。当复制内部数组/集合的成本过高时，这种放松通常包括泄漏内部数组/集合。而且这样做总是让我感到不舒服......
Simply, I prefer to use strong encapsulation in all non-private APIs that I design/implement.
The only case where habitually don't use strong encapsulation is with private nested classes that are (and need to be) little more than ersatz
structdeclarations. My reasoning is that the private class is sufficiently encapsulated by being nested and private.I am also prepared to relax encapsulation (a bit) if there are compelling performance reasons for doing this. This relaxation usually consists of leaking internal arrays / collections when the cost of copying them is prohibitive. And it always makes me feel uncomfortable doing this ...