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