照片建模用到的计算机语言,使用统一建模语言图编程 Go

Go Structs 包含属性/状态，但不包含方法，以及使用 Structs 作为参数的方法/函数(即使是那些执行魔术以使 Struct 看起来像对象的方法)，不包含方法或状态。

您可能知道，在 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，其中包含指向它实现和/或继承的方法的函数指针。

此外，方法不包含状态，至少在当代编程世界中不包含状态。这是否意味着我应该使用另一种方法论来为 Go 程序建模，或者 UML 是否对语言结构进行了充分建模？

UML 应该足够了。是时候采用一种新的(消灭思想！)图表技术，为行为不再受对象控制的美丽新世界了吗？

呐。是否可以在不参考其影响的状态的情况下对行为进行建模？

是的，这就是接口的用途。我正在尝试数据流图，看看它们是否更适合范式。到目前为止一切顺利，但我认为当我对结构的方法建模时，我会陷入困境，DFD 中的妥协是它们被视为函数。:(

不要迷失在抽象中，打破它们。没有完美的范式，也永远不会有。