Overuse of mixin is evil and what are the alternative solutions?

Question

Sometimes using mixin with multiple inheritance can help us improve reusability of our code.

For example, the following design

class FollowableMixin(object):
    def get_followers(self):
        ...
    ...

class User(FollowableMixin):
    ...

may be better reused than simply adding get_followers to User:

class User(object):
    def get_followers(self):
        ...
    ...

because later we may consider supporting other followable entities that are potential clients of get_followers:

class BookStore(FollowableMixin):
    ...

However, if this pattern is overused, code may get too complex.

class User(FollowableMixin, RunnableMixin, FlyableMixin, WhatMixin ...):
    ...

With all these mixin classes injecting properties and methods to your class, it becomes very difficult to understand your code. For example, you don't know where the method you are calling is from, and this method may in turn include an invocation of a method in another mixin ...

What should I do to simplify this programme?

Answer 1

Sometimes it can help to collect together related features in a single class if they are often used together.

class FooMixin(FollowableMixin, RunnableMixin):
    pass

Then when you come to use it you only have one or two direct base classes instead of many.

Obviously you should only do this if it makes sense - it can be abused. Without knowing more about your specific example it is hard to know whether it makes sense to do this or not in your case.

Answer 2

If your User class really has that many characteristics that are appropriate, then you may simply have a complex application. Having five mixins is better than having five functions copied from other places.

Some possibilities for simplifying:

1. Your User class is trying to do too much. Break it into smaller classes.

2. Aggregate some of your mixins. For example, you may find there are five classes each of which is Followable and Runnable and Flyable. Makes an intermediate class FollowRunFly that derives from those three mixins, then use FollowRunFly in your five classes.

3. Perhaps you don't have to slice your mixins so finely. Make one big mixin, and use it on your classes, and let the code determine at runtime whether the object can fly or be followed.