我应该包括吸气剂和吸气剂吗？类图中的设置器？
我需要为项目文档的 JSF 应用程序绘制类图。所以我有很多类作为托管 bean，有很多属性，因此有很多 getter 和 setter。
当我绘制类图时，我还应该包括吸气剂和吸气剂吗？图表中的设置者还是我可以简单地保留它们？
I am required to draw a class diagram for my JSF application for a project documentation. So I have lots of classes as managed beans, with many attributes therefore many getters and setters.
When I draw the class diagram should I also include the getters & setters in the diagram or can I simply leave them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
将它们包括在内是不合适的。您只需添加一行访问器方法
It wouldn't be appropriate to include them. You can just add one line saying accessors methods
包含 getter 和 setter 是个坏主意。他们浪费“空间”来重复已在类的属性/属性部分中显示的信息。
其他答案表明 UML 图需要记录 Java getter 和 setter 的“不寻常”可见性，或者 getter 和 setter 中的“特殊”行为。
我想在某些情况下这是合理的。然而，我反驳说：
UML 图不需要显示所有内容。只做重要的事情。事实上，一个好的 UML 图的标志之一就是它没有混杂着不重要的东西。因此，只有当这些细节确实很重要时才应包含在内。
抽象边界的细节通常不是设计所关心的。 Java 程序员应该只知道在需要时如何实现抽象/封装的基础知识。此外，程序员很可能对需要“多孔”抽象边界的情况有更好的洞察力；例如出于性能原因。 （UML 不是为了表达这种事情而设计的。）
字段和方法的精确行为通常不是 UML 设计文档所关心的。 （除非设计者还要在 OCL 中详细指定方法的前置条件、后置条件和不变量！）但是，如果 UML 图需要表明某个字段永远不能是
null，或者获取字段会增加计数器，您应该能够将其描述为字段上的注释（或 OCL 约束）。最后，UML 图不应该是软件的唯一技术文档。 javadoc 自动记录方法和字段的访问修饰符/可见性。同样，如果程序员实现了具有需要记录的“特殊”行为的 getter 和 setter，则应在 javadoc 注释中对此进行描述。
Including getters and setters would be a bad idea. They are wasting "real estate" to duplicate information that is already shown in the attribute / property section of the class.
Other answer suggest that the UML diagram needs to document "unusual" visibility of Java getters and setters, or "special" behavior in getters and setters.
I guess in some cases that could be justified. However, I would counter that:
A UML diagram doesn't need to show everything. Only the important things. Indeed, one of the signs of a good UML diagram is that it isn't cluttered up with unimportant things. So these details should only be included if they are really important.
The fine details of the abstraction boundaries are generally not the concern of the design. A Java programmer should just know the basics of how to implement abstraction / encapsulation when it is needed. Furthermore, the programmer will most likely have a better insight into situations where "porous" abstraction boundaries are needed; e.g. for performance reasons. (UML is not designed to express that kind of thing.)
The precise behavior of fields and methods is generally not the concern of the UML design documents. (Unless the designer is also going to go to the length of specifying methods' preconditions, postconditions and invariants in OCL!) However, if a UML diagram needs to say that a field can never be
null, or that getting a field increments a counter, you should be able to describe that as comments (or OCL constraints) on the field.Finally, the UML diagram should not be the only technical documentation for the software. The javadocs automatically document the access modifiers / visibility of methods and fields. Likewise, if the programmer has implemented getters and setters with "special" behavior that needs documenting, this should be described in the javadoc comments.
不应在图表中包含 getter 和 setter，除非它们执行一些特殊操作：空检查等。但这是糟糕设计的标志，因此一般答案是“不，你不应该”。
You should not include getters and setters in your diagram until they do something special: null checking and so on. But it is a sign of bad design, so general answer is "No, you should not".
UML 是一种相当非正式的表示法，最好是首先设置您将在项目或组织中使用的规则。
例如，通常隐藏 getter 和 setter，但有时显示所有细节也很重要。规则可能是这样的：
如果您的属性是使用私有变量和一对具有相同可见性的 getter 和 setter 来实现的，那么您只需创建具有此可见性的属性即可。
如果您的属性是使用私有变量实现的，但 getter 和 setter 具有不同的可见性，例如公共 getter 和受保护的 setter，则建议在模型中显示 getter 和 setter。
所以儿子...
UML is a rather informal notation, the best would be to first set the rules you going to use at your project or organization.
For instance, it is usual to hide getters and setters, but sometimes it is important to show all details. A rule could be such as:
if your property is implemented with a private variable and a pair of getters and setters with the same visibility, you just create a property with this visibility.
if your property is implemented with a private variable, but the getter and setter has distinct visibilities, such as a public getter and a protected setter, it would be advisable to show the getter and setter in the model.
and so son...
通过创建您自己的用于对这些私有属性进行分类的“get/set”和“get”构造型，使相关属性的 getter/setter 约定明确可能很有用。请参阅我对 的回答在 UML 类图中表示或暗示 getter 和 setter 的快捷方式。
It may be useful to make the getter/setter convention explicit for the properties concerned by creating your own «get/set» and «get» stereotypes to be used for categorizing these private properties. See my answer to Shortcut for denoting or implying getters and setters in UML class diagrams.