0

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

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

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

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

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

这只是让我有些烦恼的事情，我希望有人能给出答案。

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

4

2 回答 2

3

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

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

于 2013-11-08T05:14:38.513 回答
1

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

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

struct Object {
  ...
};

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

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

于 2013-11-08T05:07:17.170 回答