CLOS 相对于其他基于类的 OO 系统的优势
我曾遇到过这样的说法：Common Lisp 对象系统 (CLOS) 优于传统的（基于类的）面向对象系统。 CLOS 的维基百科条目 提到了两种方法之间的差异 - 主要是多重分派以及类和方法的分离在 CLOS 中。这些仅仅是差异还是 CLOS 的真正优势？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
取决于您认为优势是什么。
首先，与非基于类的面向原型的对象系统相比，CLOS 是一个基于类的对象系统。 CLOS 具有具有多重继承的类。 CLOS 对象是类的实例。
CLOS 不创建类名称空间。 CLOS 也不使方法驻留在类和这些类的命名空间内。
这意味着CLOS 不是消息传递面向对象。人们不会将消息传递给某个对象，然后该对象将运行相应的方法。
历史上早期的 Lisp 对象系统（CLOS 就是从该系统开发出来的）最初是作为传统的基于类和消息传递系统 (循环，口味）。经过几年的实验和研究，CLOS 模型被认为更适合 Lisp，并且更强大。
CLOS 使用通用函数模型，其主要优点是它更适合函数式编程范式。 CLOS 使用通用函数的函数调用。泛型函数可以有多个参数，并且可以分派多个参数。
这适合 Common Lisp 的其余部分，因为其他函数也可以有多个参数。 CLOS 泛型函数也可以传递、从函数返回或存储在数据结构中。所以它们也是一流的函数。如果你发现这些东西（高阶函数和多重分派）有用，那么 CLOS 有优势。另外，CLOS 通用函数本身就是 CLOS 对象。
有一些事情与其他基于类的 OO 系统不同 - 每个类缺乏命名空间，并且方法不是按类组织的，上面已经提到了。由于 CLOS 不是消息传递 OO，因此将发送到某个对象的所有消息转发到另一个对象并不适用 - 如果没有消息传递，我们就无法转发不存在的消息。
一个明显的可能优点是，由于 CLOS 类不捆绑方法并且可以单独定义方法，因此类和方法集不是封闭的。人们可以随时添加或删除新方法。这意味着对于新的或更改的功能，不需要源代码，以某种方式“重新打开”一个类，甚至对一个类进行子类化即可将新功能添加到子类中。所有这些在 CLOS 中都不是必需的。
其他一些可能的优点：
CLOS 具有用于组织功能的通用函数。因此，功能不需要分散在类中，而是可以集中在通用函数中。
CLOS的调度机制极其灵活。在运行时，有效方法可以从一组适用方法组装而成，并且可以用几乎任意方式控制组装。这样用户就可以实现新的调度方式，而无需更改底层实现。一个例子是按合同设计的实施。 CLOS非常灵活，可以由用户来实现。
一般来说，高级 CLOS 实现基于这样的想法：它是默认对象系统，但允许对对象系统本身进行各种自定义。因此，CLOS 定义了一个可能的对象系统区域，而不是一个固定的区域。默认功能已经相当先进：多重继承、动态更新、多重分派、方法组合等等。
要了解有关 CLOS（Common Lisp 对象系统）设计理念的更多信息，请参阅以下论文：
Depends on what you see as advantage.
First CLOS is a class-based object system, compared to non-class-based prototype-oriented object systems. CLOS has classes with multiple inheritance. CLOS objects are instances of classes.
CLOS does not make classes namespaces. CLOS also does not make methods reside inside classes and namespaces of those classes.
This means that CLOS is not message-passing OO. One does not pass a message to some object, where the object then runs the corresponding method.
Historically earlier object systems for Lisp, from which CLOS was developed, started as traditional class-based and message-passing systems (LOOPS, Flavors). With several years of experimentation and research the CLOS model was seen to fit better into Lisp and to be more powerful.
CLOS uses a generic function model, whose main advantage is that it fits better into a functional programming paradigm. CLOS uses function calling of generic functions. The generic function can have more than one argument and can dispatch on more than one argument.
This fits into the rest of Common Lisp, since other functions also can have more than one argument. CLOS generic functions can also be passed around, returned from functions or be stored in data structures. So they are also first-class functions. If you find these things (higher-order functions and multiple dispatch) useful, then CLOS has an advantage. Additionally CLOS generic functions are CLOS objects themselves.
A few things then are different from other class-based OO-systems - the lack of a namespace per class and that methods are not organized by class is already mentioned above. Since CLOS is not message-passing OO, forwarding all messages sent to some object to another object does not apply - if there is no message-passing we cannot forward non-existant messages.
One obvious possible advantage is that since CLOS class do not bundle methods and methods can be defined individually, a class and the set of methods is not closed. One can add or remove new methods at any time. This means that for new or changed functionality, one does not need the source code, somehow 're-open' a class or even subclass a class to add the new functionality to a subclass. All that is not necessary in CLOS.
A few other possible advantages:
CLOS has for organizing functionality the generic function. Thus functionality does not need to be scattered around classes, but can be brought together in generic functions.
the dispatch mechanism of CLOS is extremely flexible. At runtime the effective method can be assembled from a set of applicable methods and the assembly can be controlled in almost arbitrary ways. This way new dispatching ways can be implemented by the user without the need to change the underlying implementation. An example is the implementation of Design by Contract. CLOS is so flexible that this can be implemented by a user.
Generally the advanced CLOS implementations are based on the idea that it is a default object system, but allows a wide variety of customizations of the object-system itself. Thus CLOS is defines a region of possible object-systems and not a single fixed one. The default functionality is already quite advanced: multiple inheritance, dynamic updates, multi-dispatch, method combinations, and more.
To read more about the design philosophy of CLOS, the Common Lisp Object System, see these papers: