我刚开始使用Go（GoLang），我发现它是一种很棒的语言。但是，经过多年的UML和面向对象的方法，我发现建模Go程序（逆向工程）有点问题，因为Go Structs包含属性/状态，但没有方法，以及使用Structs作为参数的方法/函数（即使那些做魔法使它使一个Struct看起来像一个对象），也不包含方法或状态。
这是否意味着我应该使用另一种方法来建模Go程序，或者UML是否对语言结构进行了充分的建模？
是的我知道如果你在Structs上使用方法，可以通过结构和结构方法的组合将UML中对象的行为映射到Go，但我发现这是错误的，阻抗不匹配在各种范式中。
对于一个行为不再受物体控制的勇敢新世界，是时候采用新的（消失思想！）图表技术吗？行为可以建模而不参考它正在影响的状态？
更新
我正在尝试数据流图，看看它们是否更适合范式。到目前为止一切都那么好，但我认为当我对Struct的方法进行建模时，我将会失败，DFD中的折衷方案是它们被视为函数。 ：（
Go支持继承！ arghhh！ （头被吹干净。）你可以组成一个由另一个结构组成的结构，它有方法，子结构现在继承了......你得到了吗？我的思绪被吹了。意味着UML有效......完全但感觉很脏。
Go不支持继承，它就是这样。 :) DFD就是这样！
答案 0 :(得分：5)
方法在结构本身的定义之外声明的事实不应该是重要的;它只是一个小的语法差异。这些方法属于结构类型，就像它们在大括号内一样。 （它们在括号之外声明，因为方法不限于结构。）
在Go中使用UML的真正潜在问题是UML通常与传统的面向对象设计（即类层次结构）一起使用，而Go采用不同的继承和多态方法。也许UML可以适应Go的类型系统 - 我对UML不太熟悉 - 但是你的设计方法可能需要在某种程度上改变，无论你是否继续使用UML。
Go不打算用于Smalltalk和Java的所有对象样式。惯用Go程序通常包含很大比例的程序代码。如果您的设计过程侧重于对象建模，那么Go将无法正常工作。
答案 1 :(得分：3)
UML仍然为您提供了用于分析和设计组件，接口和数据的工具。 Go不是OO语言，所以你不能使用继承，多态，方法等。你不需要新的范例，你可能需要一个旧的范例：Structured Analysis and Structured Design。
答案 2 :(得分：0)
Go Structs包含属性/状态，但没有方法，和 使用Structs作为参数的方法/函数（即使是那些 做魔术，使它看起来像一个对象），不包含 方法，或状态。
正如您所知，在C ++中，您还可以在结构上声明方法 - 就像在类中一样，唯一不同的是您将无法使用访问修饰符。
在OOP语言中，您在类定义中声明了类的方法，让人觉得这些方法在某种程度上是类的一部分。对于大多数语言来说，情况并非如此，Go使这一点显而易见。
当您使用传统的OOP语言声明类似以下伪代码的内容时：
class Foo {
public function bar(x int) {
// ...
}
}
链接器将导出一个类似于：
的函数Foo__bar(this Foo, x int)
当你这样做时（假设f是Foo的实例）：
f.bar(3)
你实际上（并间接地，稍后会更多）做：
Foo__bar(f, 3)
类实例本身只包含一个所谓的 vtable ，其函数指向它实现和/或继承的方法。
此外，方法不包含状态，至少在当代编程世界中不存在。
这是否意味着我应该使用另一种Methodology来模拟Go 程序或UML是否足以为语言结构建模？
UML就足够了。
是时候换新的（毁掉思想！）图表技术了 行为不再由一个人控制的勇敢的新世界 对象
萘乙酸。
可以在不参考状态的情况下对行为进行建模 影响？
是的，这就是接口的用途。
我正在尝试数据流图，看看它们是否更适合 范例。到目前为止一切都那么好，但我想我什么时候才会失败 我为结构的方法建模，在DFD中的折衷就是这样 它们被视为功能。 ：（
不要迷失在抽象中，打破它们。没有完美的范例，永远不会有。
答案 3 :(得分：-1)
如果您更喜欢规划和建模而不是编程，那么您应该坚持使用Java。
如果您想构建和维护实际的代码和工作系统，您应该尝试在一张纸或白板上规划您的Go程序并进行编程。