有没有办法为 groovy 或 python 等动态脚本语言规划和绘制架构图？
假设我想用 groovy 编写一个大型应用程序，并利用闭包、类别和其他概念（我经常使用它们来分离关注点）。 有没有一种方法可以用图表或其他方式以简单的方式传达其中一些内容的架构？ 例如，您如何详细说明（没有详细的文档）闭包映射可能执行的操作？ 据我所知，通常不建议大规模使用动态语言功能，因为它们被视为复杂，但情况是否一定如此？
Say I want to write a large application in groovy, and take advantage of closures, categories and other concepts (that I regularly use to separate concerns). Is there a way to diagram or otherwise communicate in a simple way the architecture of some of this stuff? How do you detail (without verbose documentation) the things that a map of closures might do, for example? I understand that dynamic language features aren't usually recommended on a larger scale because they are seen as complex but does that have to be the case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
UML 没有足够的能力来处理此类事情，但如果您愿意做一些心理绘图，您仍然可以使用它来传达您的设计。 您可以发现大多数动态概念和 UML 静态对象模型之间的同构。
例如，您可以将闭包视为实现单一方法接口的对象。 将此类接口建模为比interface Callable { call(args[0..*]: Object) : Object }更具体的东西可能很有用。
鸭子打字同样可以看作是一个界面。 如果您有一个方法采用可以嘎嘎叫的东西，请将其建模为采用接口 _interface Quackable { quack() } 的特化对象。
您可以发挥您的想象力来理解其他概念。 请记住，设计图表的目的是交流想法。 因此，不要过于迂腐地对所有内容进行 100% 建模，想想您希望图表表达什么，确保它们表达了这一点，并消除任何会淡化信息的无关细节。 如果您使用的一些概念对目标受众而言并不明显，请对其进行解释。
另外，如果 UML 确实无法处理您想说的内容，请尝试其他方法来可视化您的消息。 UML 是一个不错的选择，因为它为您提供了通用词汇表，因此您不必解释图表上的每个概念。
UML isn't too well equipped to handle such things, but you can still use it to communicate your design if you are willing to do some mental mapping. You can find an isomorphism between most dynamic concepts and UMLs static object-model.
For example you can think of a closure as an object implementing a one method interface. It's probably useful to model such interfaces as something a bit more specific than interface Callable { call(args[0..*]: Object) : Object }.
Duck typing can similarly though of as an interface. If you have a method that takes something that can quack, model it as taking an object that is a specialization of the interface _interface Quackable { quack() }.
You can use your imagination for other concepts. Keep in mind that the purpose of design diagrams is to communicate ideas. So don't get overly pedantic about modeling everything 100%, think what do you want your diagrams to say, make sure that they say that and eliminate any extraneous detail that would dilute the message. And if you use some concepts that aren't obvious to your target audience, explain them.
Also, if UML really can't handle what you want to say, try other ways to visualize your message. UML is only a good choice because it gives you a common vocabulary so you don't have to explain every concept on your diagram.
如果您不想生成冗长的文档，一张图片胜过一千个单词。 我发现像 FreeMind 这样的工具很有用，既可以澄清我的想法，也可以将它们传达给其他人。 如果您愿意投资中等（或至少更高）级别的文档，我会推荐 Sphinx 。 它非常容易使用，虽然它是面向 Python 模块的文档，但它可以生成完全通用的文档，看起来专业且易于阅读。 您的文档可以包含使用 Graphviz 创建的图表。
If you don't want to generate verbose documentation, a picture is worth a thousand words. I've found tools like FreeMind useful, both for clarifying my ideas and for communicating them to others. And if you are willing to invest in a medium (or at least higher) level of documentation, I would recommend Sphinx. It is pretty easy to use, and although it's oriented towards documentation of Python modules, it can generate completely generic documentation which looks professional and easy on the eye. Your documentation can contain diagrams such as are created using Graphviz.