建议 51：用 mixin 模式让程序更加灵活

建议 51：用 mixin 模式让程序更加灵活

模板方法模式就是在一个方法中定义一个算法的骨架，并将一些实现步骤延迟到子类中。模板方法可以使子类在不改变算法结构的情况下，重新定义算法中的某些步骤。

来看一个例子：

class People(object):
    def make_tea(self):
        teapot = self.get_teapot()
        teapot.put_in_tea()
        teapot.put_in_water()
        return teapot

显然get_teapot()方法并不需要预先定义，也就是说我们的基类不需要预先申明抽象方法，子类只需要继承 People 类并实现get_teapot()，这给调试代码带来了便利。

但我们又想到如果一个子类 StreetPeople 描述的是正走在街上的人，那这个类将不会实现get_teapot()，一调用make_tea()就会产生找不到get_teapot()的 AttributeError，所以此时程序员应该立马想到，随着需求的增多，越来越多的 People 子类会选择不喝茶而喝咖啡，或者是抽雪茄之类的，按照以上的思路，我们的代码只会变得越发难以维护。

所以我们希望能够动态生成不同的实例：

class UseSimpleTeapot(object):
    def get_teapot(self):
        return SimpleTeapot()

class UseKungfuTeapot(object):
    def get_teapot(self):
        return KungfuTeapot()

class OfficePeople(People, UseSimpleTeapot): pass

class HomePeople(People, UseSimpleTeapot): pass

class Boss(People, UseKungfuTeapot): pass

def simple_tea_people():
    people = People()
    people.__base__ += (UseSimpleTeapot,)
    return people

def coffee_people():
    people = People()
    people.__base__ += (UseCoffeepot,)

def tea_and_coffee_people():
    people = People()
    people.__base__ += (UseSimpleTeapot, UserCoffeepot,)
    return people

def boss():
    people = People()
    people.__base__ += (KungfuTeapot, UseCoffeepot, )
    return people

以上代码的原理在于每个类都有一个__bases__属性，它是一个元组，用来存放所有的基类，作为动态语言，Python 中的基类可以在运行中可以动态改变。所以当我们向其中增加新的基类时，这个类就拥有了新的方法，这就是混入mixin。

利用这个技术我们可以在不修改代码的情况下就可以完成需求：

import mixins   # 把员工需求定义在 Mixin 中放在 mixins 模块

def staff():
    people = People()
    bases = []
    for i in config.checked():
        bases.append(getattr(maxins, i))
    people.__base__ += tuple(bases)
    return people

 

mixin也是为了代码复用，有两个主要的使用场景:

• 你希望给一个类提供很多可选的特征(feature).
• 你希望在很多不同的类中使用一个特定的特征(feature).

 

二、

通过调研，客户发现两件事实：一是现在的年青人还是不懂送人应该买什么水果和什么水果可以用来送人这两个问题；二是水果连锁店的营业员100％都是年青人，他们也不懂。

所以，客户决定在软件中必须提供一个这样的功能－－可以查询一种水果是否适宜送人。

最初，你可能这样设计：

class Fruit(object):

       pass

把fruit类作为一切水果的基类，嗯，这相当明智。代码中去除了一些无需关注的代码，如价格、产地等。

现在你打算实现最受顾客欢迎的苹果：

class Apple(Fruit):

       def is_gift_fruit(self):

              return True

同样的，我又去除了一些无需关注的代码，并且打算在接下来的行文中不再提醒这一点。

Apple is a fruit。所以上面的实现挺符合OO的原则。

接下来让我们实现梨子吧：

class Pear(Fruit):

       def is_gift_fruit(self):

              return False

解决问题了。如果水果连锁店只卖苹果和梨子两种水果的话。

可惜，需求很多，你还要实现桔子和香蕉呢。你写下了这几行代码：

class Orange(Fruit):

       def is_gift_fruit(self):

              return True

class Banana(Fruit):

       def is_gift_fruit(self):

              return False

好臭啊，代码的坏味道！

类apple和类Orange除了类名不同，几乎是完全重复的代码；类Pear和类Banana也是一样。

更进一层的说，这四个类都差不多啊，所以我们有必要重构一下已有代码，改善它们的设计。

改善已有代码

阅读代码，你可以发现水果只分两类：一类是可以作为礼品的，一类是不可以的。所以希望可以这样设计：

              Fruit

              /      /

       GiftFruit NotGiftFruit

       /      /      /      /

Apple        Orange Pear    Banana

嗯，加了两个中间类，看起来不错：

class GiftFruit(Fruit):

       def is_gift_fruit(self):

              return True

class NotGiftFruit(Fruit):

       def is_gift_fruit(self):

              return False

class Apple(GiftFruit):pass

class Orange(GiftFruit):pass

class Pear(NotGiftFruit):pass

class Banana(NotGiftFruit):pass

好啦，看上去很不错哦，代码精简了不少，任务完成～

新的烦恼

接下来我们来完成另一项功能：提供水果食用方法咨询。

不要笑这个需求，这是真实的市场需求。比如相当部分一辈子生活在北方的朋友就没有吃过龙眼荔枝香蕉；而南方虽然水果丰富，但不知道山竹等洋水果的也大有人在。我们这个水果连锁店业务简单，水果的食用方法也只分两种：一种是剥皮的，如桔子和香蕉；另一种是削皮的，如苹果和梨子。让我们修改原有的设计：

                     Fruit

                     /      /

              GiftFruit NotGiftFruit

              /      /      /             /

       PareG...   HuskG...     PareNot...     HuskNot...

       /             /      /             /     

Apple           Orange        Pear              Banana

不得已，我们添加了四个类：

class PareGiftFruit(GiftFruit):

       def eat_method(self):

              return 'Pare'

class HustGiftFruit(GiftFruit):

       def eat_method(self):

              return 'Husk'

class PareNotGiftFruit(NotGiftFruit):

       def eat_method(self):

              return 'Pare'

class HuskNotGiftFruit(NotGiftFruit):

       def eat_method(self):

              return 'Husk'

怎么这四个类这么像啊？汗。。。。

先忍忍，把AOPB四种水果的实现改改：

class Apple(PareGiftFruit):pass

class Orange(HuskGiftFruit):pass

class Pear(PareNotGiftFruit):Pass

class Banana(HuskNotGiftFruit):pass

我已经忍无可忍了。这个设计不仅仅又引入了好不容易消除的重复代码，而且还修改了AOPB这四个类的实现。这种设计的扩展性也不好，如果以后要提供水果的其它特点，比如是进口水果还是国产水果。天啊，这还了得！加上这个特性，我要实现LocalPareGiftFruit、LocalHuskGiftFruit等类共8个（2的三次方）啊。水果的特征多得很，随便算算可能超过16种啊，65536个类？叫我去死吧～单是长达16个单词的类名我就崩溃了！

现在，你们都应该意识到这种实现方法实在是一种龌龊的设计了。那，我们应该怎么样设计呢？

Pythonic的方案

该是Mixin出场的时候了！

先来看看Mixin的实现吧：

class Fruit(object):

       pass

class GiftMixin(object):

       def is_gift_fruit(self):

              return True

class NotGiftMixin(object):

       def is_gift_fruit(self):

              return False

class PareMixin(object):

       def eat_method(self):

              return 'Pare'

class HuskMixin(object):

       def eat_method(self):

              return 'Husk'

class Apple(GiftMixin, PareMixin, Fruit):pass

class Orange(GiftMixin, HuskMixin, Fruit):pass

class Pear(NotGiftMixin, PareMixin, Fruit):pass

class Banana(NotGiftMixin, HuskMixin, Fruit):pass

编码完成！这就是Mixin，就是这么简单，以致我无法再说出任何言语，因为我觉得上面的代码已经完整地表达了我想要表达的思想。

Mixin的好处是可以为主类（如Fruit）添加任意多的Mixin来实现多态，比如刚才说的水果有进口和国产两个特征，现在相当容易实现：

class NativeMixin(object):

       def Locality(self):

              return 'Native'

class ForeignMixin(object):

       def Locality(self):

              return 'Foreign'

class Apple(ForeignMixin, GiftMixin, PareMixin, Fruit):pass #进口红富士

class Orange(NativeMixin, GiftMixin, HuskMixin, Fruit):pass

class Pear(NativeMixin, NotGiftMixin, PareMixin, Fruit):pass

class Banana(NativeMixin, NotGiftMixin, HuskMixin, Fruit):pass

简单多了，只加了两个类，对AOPB的实现也只是增加了一个基类（增加总是胜过修改）。

利用Mixin我们还可以增加无数总特征，而无需对已有代码作太大改动。

除此之外

这时候，你可能会说：水果连锁店软件只是你杜撰的一个项目，Mixin有什么实际用处吗？当然有啦！其实Mixin并不是什么高阶的Python技巧，早有就很多开源项目使用这个技巧了，典型的，比如Python项目啊！在Python自带的SimpleServer.py里就应用了Mixin来实现基于进程和基于线程的两种TCP/UDP服务模型，在Tkinter和Python的其它模块也可以见到它的踪迹，如果你留意的话。

确切来说，我对Mixin来实现的水果连锁店的实现仍然相当不满意，但如果我们想要足够面向对象，也就基本上只能接受如此解决方案了。如果有一天你不能忍受每增加一种特征你就必须编写N（N>=2）个Mixin，然后都必须给已经存在的AOPB代码增加一个基类（想想，水果店卖的可不止四种水果，你会更头大），那，就考虑把OO抛弃吧！

 

 

三、

Mixin模式是一种在python里经常使用的模式，适当合理的应用能够达到复用代码，合理组织代码结构的目的。

Python的Mixin模式可以通过多继承的方式来实现, 举例来说，我们自定义一个简单的具有嵌套结构的数据容器：

class SimpleItemContainer(object):
    def __init__(self, id, item_containers):
        self.id = id
        self.data = {}
        for item in item_containers:
            self.data[item.id] = item

SimpleItemContainer通过python内置类型Dict来存放数据，不过到目前为止想要访问对应的数据还是得直接调用里面的字典，没法像原生的字典一样方便的通过暴露出来的api访问数据。当然也可以从头开始把完整的Dictionary Interface完全实现个遍，不过在每个自定义的类似的容器中都来一套肯定不行，这时候利用python内置的UserDict.DictMixin就是一个不错的方式：

from UserDict import DictMixin

class BetterSimpleItemContainer(object, DictMixin):
    def __getitem__(self, id):
        return self.data[id]
    
    def __setitem__(self, id, value):
      self.data[id] = value
    
    def __delitem__(self, id):
      del self.data[id]
    
    def keys(self):
            return self.data.keys()

通过实现最小的Dictionary Interface，还有继承DictMixin实现Mixin模式，我们就轻松获得了完整的原生字典的行为：下表语法，get, has_keys, iteritems, itervalues甚至还有iterable protocol implementation等一系列的方法和实现。

很多框架比如Django， Django rest framework里面就普遍用到了Mixin这种模式，定义api或者viewset的时候就能够通过多重继承的方式服用一些功能

当然，Mixin模式也不能滥用，至少他会污染你新定义的类，有时候还会带来MRO的问题；不过把一些基础和单一的功能比如一般希望通过interface/protocol实现的功能放进Mixin模块里面还是不错的选择：

class CommonEqualityMixin(object):

    def __eq__(self, other):
        return (isinstance(other, self.__class__)
            and self.__dict__ == other.__dict__)

    def __ne__(self, other):
        return not self.__eq__(other)

class Foo(CommonEqualityMixin):

    def __init__(self, item):
        self.item = item

其实整个理解下来无非就是通过组合的方式获得更多的功能,有点像C#， java里面的interface，强调“it can”的意思，但相比起来简单多了，不需要显示的约束，而且mixin模块自带实现。在使用的时候一般把mixin的类放在父类的右边似乎也是为了强调这并不是典型的多继承，是一种特殊的多继承，而是在继承了一个基类的基础上，顺带利用多重继承的功能给这个子类添点料，增加一些其他的功能。保证Mixin的类功能单一具体，混入之后，新的类的MRO树其实也会相对很简单，并不会引起混乱。