Hi,

I'm working on a slightly large application and I'm trying to model it as a
some kind of plugin architecture so that it modular and I can enable or
take out features without lot of code changes.

One of the issues I faced was that the wanted to add some methods to a
class only when a feature/plugin is enabled.

Here is a simplified version of what I have:

class Place(Mixable):
    def __init__(self, name):
        self.name = name

    def get_users(self):
        return "users-of-{}".format(self.name)

    def get_links(self):
        return "links-of-{}".format(self.name)

There are couple of issues with this.

1. The logic for computing users or links doesn't really belong to this
file. I wanted to that in a separate module for modularity.

2. The Place class will become too large to manage over time.

So, I came up with the following approach to address these issues.

# place.py

class Mixable(object):
    """Magic class to allow adding mixins to the class at run-time.
    """
    @classmethod
    def mixin(cls, mixin):
        """Decorator to add a mixin to the class runtime.
        """
        cls.__bases__ = cls.__bases__ + (mixin,)

class Place(Mixable):
    def __init__(self, name):
        self.name = name

# users.py
@Place.mixin
class UsersMixin(object):
    def get_users(self):
        return "users-of-{}".format(self.name)

# links.py
@Place.mixin
class LinksMixin(object):
    def get_links(self):
        return "links-of-{}".format(self.name)

p = Place('bangalore')
print(p.get_users())
print(p.get_links())

With this I was able to split the class into 3 files and now I have
flexibility of deciding which features enable from a config file.

What do you guys think of this approach?
Is this a good practice?
Are there any know flaws in this approach?
How did you solve that issue when you faced similar situation?

Anand
_______________________________________________
BangPypers mailing list
BangPypers@python.org
https://mail.python.org/mailman/listinfo/bangpypers

Reply via email to