为什么很多窗口管理器不支持面向对象？答案

【问题标题】：Why do a lot of window managers not support object orientation?为什么很多窗口管理器不支持面向对象？
【发布时间】：2013-11-08 04:57:47
【问题描述】：

注意：我做了一个简短的搜索，结果很少，唯一真正相关的结果是this one，所以我认为以前没有人问过这个问题。

我最近一直在研究操作系统开发，我发现大多数（如果不是全部）都没有完全面向对象的窗口应用程序接口，包括 Windows。当然，除了字节码解释语言，如 C#（或一般的 CLI）和 Java，这是一个明显的例外。（澄清一下，我的意思是他们倾向于通过函数而不是通过创建类来创建窗口。

我可以理解为简单起见而制作的较小的管理器，例如 tinywm，但更大的窗口管理器（例如 MetaCity、Fluxbox 和 Openbox）往往仍然不是来自对象，而是来自功能 - - 尽管有些是用 C++ 而不是纯 C 编写的（至少据我所知）。

这可能是一个幼稚的问题，但为什么会这样呢？我知道为不支持面向对象的语言实现非面向对象的 ABI 很重要，但是为什么它也不能为 DO 的语言提供更高级别的挂钩 支持面向对象？

程序员最终拥有这样的钩子会不会更容易，因为它可以更容易地开发软件？鉴于硬件的进步，与开发更容易带来的好处相比，性能损失会不会很小？

这件事一直困扰着我，我希望有人能给出答案。

PS：如果我的理解在某些地方存在根本性错误，请随时纠正我。

【问题讨论】：

呵呵，Win32 API 是用纯 C 编写的，然后提供了面向对象的 Hooks。现在那些基于钩子的库被称为“MFC”，如果你曾经做过 MFC，那么，先生，你知道这样做是多么错误。
我没有意识到 MFC 被认为是面向对象的，因为它包含如此多的宏和非对象函数
@Bitwize 它是用 C++ 编写的，它展示了对象、类和继承：所有 Peter Wegner's OO criteria。在没有普遍接受的定义的情况下，我们不要再讨论“什么是 OO”了。
“为什么它不能也提供更高级别的钩子”？所需的工作量和支持量可能与此有关。

标签： c++ c operating-system window-managers

【解决方案1】：

这不仅仅是窗口。在myObject->method() 或myObject.method(). 中，我们现在使用的大多数操作系统都具有在 1980 年代早期设计的窗口 API（例如 Windows， X 窗口系统等）。需要考虑语言和 ABI 问题。我能想到的唯一例外是 OS/2 的独立于语言的 OO 东西，称为 System Object Model。

正式来说method(object, ...)和object.method(...)或object->method(...)没有区别，只是语法上的区别。

【讨论】：

【解决方案2】：

我认为你在某些地方可能根本就错了，但这样说是一种尴尬的方式。 :)

窗口管理器通常是面向对象的，但它们不是围绕类和对象设计的，就像您在 C++ 中可能发现的那样。你倾向于拥有的东西是：

struct Object {
  ...
};

void DoSomething(Object* obj, ...);

窗口管理器提供的所有功能都操作对象的内部，无论是按钮、窗口还是其他小部件。大多数时候，程序员应该不透明地处理这些对象，让 API 管理它们的内容。作为程序员，您仍在使用对象以及这些对象上的方法。只是大部分耦合被破坏了，它看起来不像人们期望的面向对象编程的样子，因为对象是函数的参数，而不是函数是对象的属性。

【讨论】：

我认为结构不像类结构那样被视为对象，因为它们不能包含方法？也许我只是将窗口生成/创建与 Java 进行了过多的比较，但我发现从类创建应用程序比使用一系列函数/句柄/宏来处理它更直观。
在 C++ 中，struct 和 class 之间的唯一区别是 struct 默认可见性是 public 和 class 是 private。在 C 结构中，您不会获得成员函数。 C++ 成员函数通常最终会为 myobj->DoSomething(...) 调用一些看起来像 MyObject::DoSomething(myobj, ...) 的东西，类变量绑定在本地范围内。结构和类在内存中的实际数据布局几乎相同。没有真正的理由说结构类型的事物不是对象。这一切都归结为调用语法。