design-patterns - 使用 Go，我应该如何访问传统基于继承的 GUI 框架中的窗口组件？

Question

我正在使用 GTK bindings for Go 做一些实验性工作.

与大多数 GUI 框架一样，GTK GUI 应用程序通常会生成一个主窗口，并且应用程序的工作是在该窗口的上下文中完成的。

当您用 C++ 编写 GTK GUI 应用程序时，您继承自框架窗口类 - gtk.Window - 并将应用程序的其他 GUI 组件声明为继承窗口类的公共(public)成员 (或在您的窗口类中使用公共(public)访问方法)。这样它们就可以由窗口 Controller 类进行操作。它按名称将它们作为窗口类的成员进行寻址。您只需将指向主窗口的指针传递给 Controller ​​类，然后通过编写 mWindow.MyWidget.text="text" 等操作其成员。同样，据我所知，大多数 GUI 应用程序的设计都是类似的，无论正在使用的 GUI 框架。

但是，由于 Go 不支持继承，所以这个选项是不可能的:当你在 Go-Gtk 窗口中实例化额外的 GUI 组件时，它们是自立变量，而不是父窗口类的成员 - 它们不是“活”在容器类中。这意味着您的 GUI Controller 类必须单独访问主窗口中的每个组件，没有内聚结构或单一引用可供引用。这会影响可读性和良好的代码组织，IMO - 迫使您的代码结构有些糟糕。

我相信在 Go 中解决这个问题的方法是声明一个结构/接口(interface)，作为所有主窗口 GUI 组件的容器。该接口(interface)将发布组件的访问方法，并可以传递给 GUI Controller 单元以操纵其成员。

我需要知道是否有针对此类任务的标准惯用 Go 设计模式，或者使用 Go 解决此问题的正确方法是什么。

我知道 Go 被设计成一种系统编程语言，并不是真正为前端开发而设计的，但我听说“每一种优秀的系统语言最终都会成为用于应用程序”，并且今天没有比 Go 更好的系统语言了——证据是许多用于 GUI 框架和其他应用程序任务的 Go 绑定(bind)正在浮出水面。看看 A list of Go projects.

我想从这一切中得出的结论是，Go 的设计目的不是为了让桌面 GUI 应用程序的开发变得容易，这是一个濒临灭绝的品种。

Answer 1

如果我必须在 Go 中编写带有 GUI 的应用程序，我会完全将 GUI 部分与应用程序部分分离。这种方法的一个例子是 GTK Server .

只是，您不需要单独的进程来处理 GUI:您可以在 goroutine 中执行此操作，它使用 channel 与应用程序的其余部分进行通信，就像 Gtk 服务器使用套接字/管道/消息队列的方式一样.

我不知道有谁使用过这种方法，我自己只在一个构建拟态 Tk GUI 的玩具程序中使用过它(使用 Tk 是因为它有一个内置的解释器并且还不知道 gtk-服务器)。但这对我来说是在 Go 中构建 GUI 应用程序的惯用方式。