mixin与多重继承的区别是什么?这只是语义上的问题吗?

mixin是一种有限形式的多重继承。在某些语言中，向类中添加mixin的机制(就语法而言)与继承的机制略有不同。

特别是在Python上下文中，mixin是一个父类，它为子类提供功能，但并不打算自己被实例化。

你可能会说，“这只是多重继承，而不是真正的mixin”，因为可能被混淆为mixin的类实际上可以被实例化和使用——所以这确实是语义上的，而且非常真实的区别。

多重继承示例

这个例子，来自文档，是一个OrderedCounter:

类OrderedCounter(计数器，OrderedDict): “计数器，记住第一次遇到的顺序元素” def __repr__(自我): 返回'%s(%r)' % (self.__class__. zip)。__name__ OrderedDict(自我) def __reduce__(自我): 回归自我。__class__进行(OrderedDict(自我),)

它从集合模块继承了Counter和OrderedDict。

Counter和OrderedDict都打算被实例化并单独使用。然而，通过将它们都子类化，我们可以拥有一个有序的计数器，并重用每个对象中的代码。

这是一种重用代码的强大方法，但也可能产生问题。如果发现其中一个对象存在bug，那么不加注意地修复它可能会在子类中创建一个bug。

Mixin的例子

mixin通常被推广为一种获得代码重用的方式，而不会出现协作多重继承(如OrderedCounter)可能存在的潜在耦合问题。当您使用mixin时，您使用的功能与数据不是紧密耦合的。

与上面的例子不同，mixin不打算单独使用。它提供了新的或不同的功能。

例如，标准库在socketserver库中有两个mixin。

可以创建每种类型服务器的分叉和线程版本 使用这些混合类。例如，ThreadingUDPServer是 创建如下: 类ThreadingMixIn, UDPServer: 通过 mix-in类首先出现，因为它覆盖了定义在 UDPServer。设置各种属性还会改变的行为 底层服务器机制。

在这种情况下，mixin方法覆盖UDPServer对象定义中的方法，以实现并发性。

重写的方法似乎是process_request，它还提供了另一个方法process_request_thread。这是来自源代码:

class ThreadingMixIn: """Mix-in class to handle each request in a new thread.""" # Decides how threads will act upon termination of the # main process daemon_threads = False def process_request_thread(self, request, client_address): """Same as in BaseServer but as a thread. In addition, exception handling is done here. """ try: self.finish_request(request, client_address) except Exception: self.handle_error(request, client_address) finally: self.shutdown_request(request) def process_request(self, request, client_address): """Start a new thread to process the request.""" t = threading.Thread(target = self.process_request_thread, args = (request, client_address)) t.daemon = self.daemon_threads t.start()

一个虚构的例子

这是一个主要用于演示目的的mixin -大多数对象将会进化到超出这个repr的有用性:

class SimpleInitReprMixin(object):
    """mixin, don't instantiate - useful for classes instantiable
    by keyword arguments to their __init__ method.
    """
    __slots__ = () # allow subclasses to use __slots__ to prevent __dict__
    def __repr__(self):
        kwarg_strings = []
        d = getattr(self, '__dict__', None)
        if d is not None:
            for k, v in d.items():
                kwarg_strings.append('{k}={v}'.format(k=k, v=repr(v)))
        slots = getattr(self, '__slots__', None)
        if slots is not None:
            for k in slots:
                v = getattr(self, k, None)
                kwarg_strings.append('{k}={v}'.format(k=k, v=repr(v)))
        return '{name}({kwargs})'.format(
          name=type(self).__name__,
          kwargs=', '.join(kwarg_strings)
          )

用法是:

class Foo(SimpleInitReprMixin): # add other mixins and/or extend another class here
    __slots__ = 'foo',
    def __init__(self, foo=None):
        self.foo = foo
        super(Foo, self).__init__()

和用法:

>>> f1 = Foo('bar')
>>> f2 = Foo()
>>> f1
Foo(foo='bar')
>>> f2
Foo(foo=None)

mixin是一种特殊的多重继承。使用mixin的主要情况有两种:

您希望为类提供大量可选特性。 你想在很多不同的类中使用一个特定的特性。

对于第一个例子，考虑werkzeug的请求和响应系统。我可以这样创建一个普通的request对象:

from werkzeug import BaseRequest

class Request(BaseRequest):
    pass

如果我想添加接受报头支持，我会这样做

from werkzeug import BaseRequest, AcceptMixin

class Request(AcceptMixin, BaseRequest):
    pass

如果我想让一个请求对象支持接受头，标签，身份验证和用户代理支持，我可以这样做:

from werkzeug import BaseRequest, AcceptMixin, ETagRequestMixin, UserAgentMixin, AuthenticationMixin

class Request(AcceptMixin, ETagRequestMixin, UserAgentMixin, AuthenticationMixin, BaseRequest):
    pass

区别是微妙的，但是在上面的例子中，mixin类并不是独立存在的。在更传统的多重继承中，AuthenticationMixin(例如)可能更像Authenticator。也就是说，这个类可能被设计成独立存在的。

我只是使用一个python mixin来实现python milters的单元测试。通常情况下，milter会与MTA交谈，这使得单元测试变得困难。测试mixin覆盖了与MTA对话的方法，并创建了一个由测试用例驱动的模拟环境。

所以，你使用一个未修改的milter应用程序，比如spfmilter，然后mixin TestBase，像这样:

class TestMilter(TestBase,spfmilter.spfMilter):
  def __init__(self):
    TestBase.__init__(self)
    spfmilter.config = spfmilter.Config()
    spfmilter.config.access_file = 'test/access.db'
    spfmilter.spfMilter.__init__(self)

然后，在milter应用程序的测试用例中使用TestMilter:

def testPass(self):
  milter = TestMilter()
  rc = milter.connect('mail.example.com',ip='192.0.2.1')
  self.assertEqual(rc,Milter.CONTINUE)
  rc = milter.feedMsg('test1',sender='good@example.com')
  self.assertEqual(rc,Milter.CONTINUE)
  milter.close()

http://pymilter.cvs.sourceforge.net/viewvc/pymilter/pymilter/Milter/test.py?revision=1.6&view=markup

这个答案旨在通过以下例子解释mixin:

自包含:简短，不需要知道任何库来理解示例。 Python，而不是其他语言。 可以理解，这里有来自其他语言(如Ruby)的例子，因为这个术语在这些语言中更常见，但这是一个Python线程。

它还应审议有争议的问题:

对于mixin的特征来说，多重继承是必要的还是不必要的?

定义

我还没有看到一个“权威”来源的引用清楚地说明什么是Python中的mixin。

我已经看到了mixin的两种可能的定义(如果它们被认为不同于其他类似的概念，如抽象基类)，人们并不完全同意哪一种是正确的。

不同语言之间的共识可能有所不同。

定义1:无多重继承

mixin是这样一个类，该类的一些方法使用了类中没有定义的方法。

因此，该类并不意味着要被实例化，而是作为基类使用。否则，实例将具有在不引发异常的情况下无法调用的方法。

一些源代码添加的约束是类不能包含数据，只能包含方法，但我不明白为什么这是必要的。然而在实践中，许多有用的mixin没有任何数据，没有数据的基类使用起来更简单。

一个经典的例子是从<=和==中实现所有比较运算符:

class ComparableMixin(object):
    """This class has methods which use `<=` and `==`,
    but this class does NOT implement those methods."""
    def __ne__(self, other):
        return not (self == other)
    def __lt__(self, other):
        return self <= other and (self != other)
    def __gt__(self, other):
        return not self <= other
    def __ge__(self, other):
        return self == other or self > other

class Integer(ComparableMixin):
    def __init__(self, i):
        self.i = i
    def __le__(self, other):
        return self.i <= other.i
    def __eq__(self, other):
        return self.i == other.i

assert Integer(0) <  Integer(1)
assert Integer(0) != Integer(1)
assert Integer(1) >  Integer(0)
assert Integer(1) >= Integer(1)

# It is possible to instantiate a mixin:
o = ComparableMixin()
# but one of its methods raise an exception:
#o != o 

这个特殊的例子可以通过functools. total_ordered()装饰器来实现，但这里的游戏是重新发明轮子:

import functools

@functools.total_ordering
class Integer(object):
    def __init__(self, i):
        self.i = i
    def __le__(self, other):
        return self.i <= other.i
    def __eq__(self, other):
        return self.i == other.i

assert Integer(0) < Integer(1)
assert Integer(0) != Integer(1)
assert Integer(1) > Integer(0)
assert Integer(1) >= Integer(1)

定义2:多重继承

mixin是一种设计模式，其中基类的一些方法使用了它没有定义的方法，并且该方法应该由另一个基类实现，而不是像定义1中那样由派生类实现。

术语mixin类指的是打算在该设计模式中使用的基类(TODO是使用该方法的基类，还是实现该方法的基类?)

判断一个给定的类是否为mixin并不容易:方法可以只是在派生类上实现，在这种情况下，我们回到定义1。你必须考虑作者的意图。

这种模式很有趣，因为它可以用不同的基类选择重新组合功能:

class HasMethod1(object):
    def method(self):
        return 1

class HasMethod2(object):
    def method(self):
        return 2

class UsesMethod10(object):
    def usesMethod(self):
        return self.method() + 10

class UsesMethod20(object):
    def usesMethod(self):
        return self.method() + 20

class C1_10(HasMethod1, UsesMethod10): pass
class C1_20(HasMethod1, UsesMethod20): pass
class C2_10(HasMethod2, UsesMethod10): pass
class C2_20(HasMethod2, UsesMethod20): pass

assert C1_10().usesMethod() == 11
assert C1_20().usesMethod() == 21
assert C2_10().usesMethod() == 12
assert C2_20().usesMethod() == 22

# Nothing prevents implementing the method
# on the base class like in Definition 1:

class C3_10(UsesMethod10):
    def method(self):
        return 3

assert C3_10().usesMethod() == 13

权威的Python事件

在官方的收藏文档展上。abc的文档明确使用术语Mixin方法。

它指出，如果一个类:

实现__next__ 继承自单个类Iterator

然后该类免费获得一个__iter__ mixin方法。

因此，至少在文档的这一点上，mixin不需要多重继承，并且与定义1一致。

文档在不同的地方当然可能是矛盾的，其他重要的Python库可能在它们的文档中使用其他定义。

本页还使用了术语Set mixin，这清楚地表明像Set和Iterator这样的类可以称为mixin类。

其他语言

Ruby:很明显，mixin不需要多重继承，就像主要的参考书如Programming Ruby和The Ruby Programming Language中提到的那样 c++:设为=0的虚方法是纯虚方法。 定义1与抽象类(具有纯虚方法的类)的定义一致。 该类不能被实例化。 定义2可以通过虚拟继承实现:两个派生类的多重继承

也许举几个例子会有所帮助。

如果您正在构建一个类，并且希望它像字典一样工作，那么您可以定义所有必要的__ __方法。但这有点麻烦。作为一种替代方法，您可以只定义一些，并从UserDict继承(除了任何其他继承)。DictMixin(移动到集合。py3k中的DictMixin)。这将自动定义字典api的所有其余部分。

第二个例子:GUI工具包wxPython允许您创建具有多列的列表控件(例如，在Windows资源管理器中显示的文件)。默认情况下，这些列表相当基本。您可以添加额外的功能，例如通过单击列标题按特定列对列表进行排序的功能，可以从ListCtrl继承并添加适当的mixins。

我认为这里有一些很好的解释，但我想提供另一个角度。

In Scala, you can do mixins as has been described here but what is very interesting is that the mixins are actually 'fused' together to create a new kind of class to inherit from. In essence, you do not inherit from multiple classes/mixins, but rather, generate a new kind of class with all the properties of the mixin to inherit from. This makes sense since Scala is based on the JVM where multiple-inheritance is not currently supported (as of Java 8). This mixin class type, by the way, is a special type called a Trait in Scala.

它在定义类的方式中有所暗示: NewClass用SecondMixin和ThirdMixin扩展了FirstMixin …

我不确定CPython解释器是否做同样的事情(mixin class-composition)，但我不会感到惊讶。同样，作为c++背景，我不会将ABC或“接口”称为等同于mixin——它们是类似的概念，但在使用和实现上有所不同。