6

我刚刚开始使用 Go (GoLang)，我发现它是一门很棒的语言。然而，经过多年的 UML 和面向对象的方法，我发现对 Go 程序进行建模（逆向工程）有点问题，因为 Go 结构包含属性/状态，但没有方法，以及使用结构作为参数的方法/函数（即使是那些可以使 Struct 看起来像对象的魔术），不包含方法或状态。

这是否意味着我应该使用另一种方法来对 Go 程序进行建模，或者 UML 是否足以对语言结构进行建模？

是的，我知道如果您在 Structs 上使用方法，UML 中对象的行为可以通过 Struct 和 Struct 方法的组合映射到 Go，但我发现这是错误的，范式中的阻抗不匹配排序。

是时候采用一种新的（消除这种想法！）图表技术，为行为不再受对象控制的勇敢新世界了吗？可以在不参考其影响的状态的情况下对行为进行建模吗？

更新：

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

Go 支持继承！！！啊啊啊！！！（头被吹得干干净净。）你可以组成一个由另一个结构组成的结构，它有方法，子结构现在继承......你明白了吗？我的心都快炸了。意味着 UML 是有效的……完全有效，但感觉很脏。

Go 不支持继承，只是看起来如此。:) DFD 就是这样！

4

4 回答 4

5

在结构本身的定义之外声明方法这一事实不应该是重要的；这只是一个小的语法差异。这些方法属于结构类型，就好像它们在大括号内一样。（它们在大括号外声明，因为方法不限于结构。）

将 UML 与 Go 一起使用的真正潜在问题是 UML 通常与传统的面向对象设计（即类层次结构）一起使用，而 Go 对继承和多态采用不同的方法。也许 UML 可以适应 Go 的类型系统——我对 UML 还不够熟悉——但是无论你是否继续使用 UML，你的设计方法都可能需要有所改变。

Go 不打算用于 Smalltalk 和 Java 的一切皆为对象的风格。惯用的 Go 程序通常包含很大比例的过程代码。如果您的设计过程侧重于对象建模，那么它不适用于 Go。

于 2013-07-30T19:44:48.303 回答
4

UML 仍然为您提供对组件、接口和数据的分析和设计有用的工具。Go 不是一门 OO 语言，所以你不能使用继承、多态、方法等。你不需要一个新的范式，你可能需要一个旧的范式：结构化分析和结构化设计。

于 2013-07-30T19:51:04.527 回答
0

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 中的妥协是它们被视为函数。:(

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

于 2013-07-31T09:03:45.690 回答
-1

如果您比编程更喜欢计划和建模，那么您应该坚持使用 Java。

如果你喜欢构建和维护实际的代码和工作系统，你应该尝试在一张纸或白板上规划你的 Go 程序并开始编程。

于 2013-07-30T19:24:21.250 回答