我刚刚开始使用 Go (GoLang)，我发现它是一门很棒的语言。然而，经过多年的 UML 和面向对象的方法，我发现建模 Go 程序(逆向工程)有点问题，因为 Go Structs 包含属性/状态，但没有方法，以及使用 Structs 作为参数的方法/函数(即使是那些施展魔法使 Struct 看起来像对象的)，也不包含方法或状态。
这是否意味着我应该使用另一种方法论来为 Go 程序建模，或者 UML 是否足以为语言结构建模？
是的，我知道如果你在 Structs 上使用方法，UML 中对象的行为可以通过 Struct 和 Struct Method 的组合映射到 Go 中，但我发现这是错误的，阻抗不匹配在各种范式中。
是时候为行为不再受对象控制的美丽新世界采用新的(打消念头!)图表技术了吗？可以在不引用行为所影响的状态的情况下对行为进行建模吗？
更新:
我正在试用数据流图，看看它们是否更适合范例。到目前为止一切顺利，但我认为当我对结构的方法建模时，我会陷入困境，DFD 中的妥协是将它们视为函数。 :(
Go 支持继承!!!啊!!! (脑袋被吹得一干二净。)你可以组成一个结构，它由另一个结构组成，它有方法，子结构现在继承了......你明白了吗？我的心被吹了。意味着 UML 是有效的……完全有效，但感觉很脏。
Go 不支持继承，只是看起来如此。 :) DFD 就是这样!
最佳答案
在结构本身的定义之外声明方法这一事实应该不重要；这只是一个很小的语法差异。这些方法属于结构类型，就好像它们在大括号内一样。 (它们在大括号外声明，因为方法不限于结构。)
在 Go 中使用 UML 的真正潜在问题是 UML 通常用于传统的面向对象设计(即类层次结构)，而 Go 采用不同的方法来实现继承和多态性。也许 UML 可以适应 Go 的类型系统——我对 UML 还不够熟悉，所以不管你是否继续使用 UML，你的设计方法可能需要有所改变。
Go 不打算用于 Smalltalk 和 Java 的一切都是对象的风格。地道的 Go 程序通常包含很大一部分过程代码。如果你的设计过程侧重于对象建模，那么它对 Go 来说效果不佳。
关于go - 使用统一建模语言图编程 Go，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17951803/