Question

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

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

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

这可能是一个天真的问题，但为什么这样做呢？我理解为不支持面向对象的语言实现非面向对象的ABI很重要，但为什么还为 DO的语言提供更高级别的钩子呢？ 支持面向对象？

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

这只是让我有点烦恼的事情，我希望有人会有答案。

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

Answer 1

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

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

Answer 2

我认为你在某个地方可能是根本错误的，但这是一种尴尬的说法。：）

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

struct Object {
  ...
};

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

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

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

2 个答案: