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

Why do a lot of window managers not support object orientation?

本文关键字：不支持 面向对象 窗口管理器 为什么      更新时间：2023-10-16

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

我

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

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

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

对于

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

这一直困扰着我，我希望有人能得到答案。

PS：如果我的理解在某处有根本错误，请随时纠正我。

这不仅仅是窗口化。就通过对象调用的方法而言，没有操作系统具有面向对象的 API，如 myObject->method() 或 myObject.method(). 我们现在使用的大多数操作系统都有 1980 年代初设计的窗口 API（例如 Windows X Window 系统等）。需要考虑语言和 ABI 问题。我能想到的唯一例外是 OS/2 的独立于语言的 OO 东西，称为系统对象模型。

从形式上讲，method(object, ...)和object.method(...)或object->method(...)之间没有区别，只是语法上的区别。

我认为你可能在某个地方从根本上错了，但这是一种尴尬的说法。 :)

窗口管理器通常是面向对象的，但它们不像您在C++中找到的那样围绕类和对象而设计。你倾向于拥有的是类似于以下内容的东西：

struct Object {
  ...
};
void DoSomething(Object* obj, ...);

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

相关文章：