类图——有用吗？
类图实际上与仅查看折叠了所有函数的类定义有何不同？我被要求写一些内容，并意识到这只是..阅读源代码..它有评论。类图的意义是什么，它与带有少量注释的定义有什么不同，以及是什么让一个好的类图比其他类图更好？
编辑：是的，源已经存在，并且早在类图之前就已经存在了。
另一个编辑：人们一直在谈论视觉与文本品味。这不是我得到的类图的定义。仍然是纯粹的文字。示例类图是一堆文本，类似于删除了函数定义的源代码。这就是我问的原因。如果是真图我就能理解。
How is a class diagram actually any different to just looking at the class definition with all the functions collapsed? I've been asked to write some and realized that this is all just .. read the source .. it has comments. What's the point of a class diagram, how is it different to even minorly commented definitions, and what makes a good class diagram better than others?
Edit: Yes, the source already exists, and did so long before the class diagrams.
Another edit: People have been talking about visual vs textual tastes. That's not the definition of class diagram I was given. It's still purely textual. The sample class diagram is a bunch of text, that resembles the source code with the function definitions cut. That's the reason that I asked. If it was a genuine diagram, I could understand.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果你有一两门课，那没有什么区别。
如果您有一个复杂的对象模型，情况就会发生变化。
而且，至少对我来说，首先查看图表来查找我想要的内容很容易，而不是查看一堆源文件。
查看图片上的类及其关系也有助于理解该项目的想法。
If you have one or two classes, that does not make a difference.
If you have a complex object model, things change.
And, at least for me, it is easy to look first at a diagram in order to look for what I want instead of looking at a bunch of source files.
Also seeing the classes on a picture and their relations helps to understand the ideas of the project.
我宁愿有源码。鉴于此，我总是可以对其进行逆向工程。
您必须问 UML 的用途是什么：它只是一种通信设备，一种将您的想法传达给其他开发人员的方式。如果 UML 有帮助，那就太好了。如果它成为维护的另一个负担，那么更喜欢具有良好单元测试的工作代码。
I'd rather have source. Given that, I can always reverse engineer it.
You have to ask what UML is for: it's just a communication device, a way to get your ideas across to other developers. If UML is helping, great. If it becomes another burden to maintain, prefer working code with good unit tests.
一个好的类图清楚地显示了每个类的职责和关联 - 在适当的抽象级别。
类图很有用，因为它们允许您在更高的粒度级别进行设计。白板上绘制的操作比源代码更容易更改。它还通过线条清晰地显示关联，而不是翻阅代码。
它们很有帮助，因为它们是从概念想法到源代码的延续。
他们让你事半功倍。
A good class diagram clearly shows each classes responsibilies and associations - at an appropriate level of abstraction.
Class diagrams are useful because they allow you to design at a higher level of granularity. Operations drawn on a white board are easier to change than source code. It also clearly shows associations through lines, rather than leafing through code.
They're helpful in that they are a segue from conceptual ideas to source code.
They let you say more with less.
如果来源已经存在，我想这就是那句古老的格言：“一图胜千言”。
对于不熟悉源代码的人来说，图表可以帮助他们更快地理解整体设计，然后阅读源代码，无论文档有多详细。有些人比其他人更注重视觉。就我个人而言，我宁愿有来源。
像许多事情一样，这可能是一个品味问题。
编辑：
我认为图表的定义是它是视觉的。但是，如果它只是一堆文本，那么我唯一能看到的一点是它提供了意图的概述，而没有不必要的实现细节。
If the source already exists, I guess it's the old adage, "A picture tells a thousand words".
For someone not familiar with the source, a diagram may help them to grok the overall design quicker then reading the source, no matter how well documented. Some people are more visual than others. Personally, I'd rather have the source.
Like many things, it's probably a matter of taste.
Edit:
I thought the definition of a diagram was that it is visual. However, if it's just a bunch of text, then the only point I can see is that it provides an overview of intent without the unnecessary implementation details.
查看图表和源代码之间的区别在于，您在查看图表（一张图片）时不需要处理与阅读源代码（数千字）一样多的数据。
根据我的经验，当我不熟悉软件的体系结构时，我发现类图非常有用。但是类图并不能取代对源代码和适当文档的需求，它们只是一种通信和生产力工具，补充了我之前提到的方法。他们的目的是了解软件架构。不得替代其他文件。类图的有用程度取决于它的质量以及它和源代码的复杂性。
不要在图表中加入太多细节。这让他们感到困惑。您会希望它们传达关系，而不是 API 和方法列表。
它们还有助于了解何时何地重构代码。使用类图以及适当的文档，您就可以了。
The difference between looking at a diagram and the source is that you don't need to process as much data when looking at the diagram (a picture) than when reading the source (says thousand words).
In my experience I've found class diagrams to be very useful when I'm not familiar with the architecture of the software. But class diagrams don't replace the need for source code and proper documentation, they're just a communication and productivity tool that complement the methods I mentioned before. Their intent is to understand the software architecture. not to replace other documentations. How useful a class diagram is depends on its quality and the complexity of it and the source code.
Don't put too much detail into the diagrams. It makes them confusing. You'll want them to communicate relationships, not API and a list of methods.
They also help to see when and where to refactor code. Use class diagrams along with proper documentation and you'll be all set.
我不太确定您对类图的定义是什么 - 听起来几乎就像您所展示的示例只有一个类一样。如果是这样，我可以理解为什么你认为这有点荒谬。
类图是一种显示类之间关系的方法 - 一个好的类图可以在一个图表中提供有关系统如何工作的大量信息，值得仔细研究。它允许不熟悉子系统的开发人员快速上手，而不会陷入实现细节的泥潭。
这是我通过快速谷歌找到的一个简单的：
http ://netbeans.org/images_www/articles/uml-class-diagram/Completed-Class-Diagram.gif
一些工具（Microsoft 的 Visual Studio 就是其中之一）包含允许您绘制一次类图并具有它会自动与代码保持最新（“同步”）。非常有用。
I'm not sure quite what definition you've been given for a Class Diagram - it sounds almost as though the example you've been shown has just one class on it. If so, I can understand why you think it's a bit ridiculous.
Class Diagrams are a way to show the relationships between classes - a good one can provide a lot of information about how your system works in one diagram that rewards careful study. It allows a developer unfamiliar with a subsystem to come up to speed quickly without getting mired in the implementation details.
Here's one simple one I found with a quick Google:
http://netbeans.org/images_www/articles/uml-class-diagram/Completed-Class-Diagram.gif
Some tools (Microsoft's Visual Studio is one) contain tools that allow you to draw a class diagram once and have it automatically kept up to date ("in synch") with the code. Very useful.