[Twisted-Python] General question on components, interfaces, etc.
I've been trying to properly understand components, interfaces, adaptors etc., as summarized here http://twistedmatrix.com/projects/core/documentation/howto/components.html and elsewhere. Although I feel like I understand the various bit & pieces, I still don't feel like I have a good grip on when these things are most useful, or that I can recognize patterns where they can be best applied. I do have the feeling that it's important though. So here's a specific example and question. Suppose I am implementing some functionality that I want to be able to easily replace with an alternate implementation, perhaps written by someone else. I can use some kind of plugin architecture, and I can specify an Interface that the plugin code is expected to provide. I can look for plugins (or have twisted.plugin do it for me), import them, allow a user config file to specify the preferred plugin to use to provide the functionality, and I can test the loaded plugin to see that it does provide the Interface. All that makes sense, but I'm not sure what it really buys me. An alternative would just be to document the expected interface (perhaps as an Interface), and then use __import__() to load the desired implementation. It seems that without needing adapters, the component architecture doesn't really buy me anything except a formalism (which I do think has value, though limited). Is this thinking more or less correct? How would people go about doing what I outline above? Regards, Terry
On Thu, 15 Jun 2006 17:24:10 +0200, Terry Jones <terry@jon.es> wrote:
All that makes sense, but I'm not sure what it really buys me. An alternative would just be to document the expected interface (perhaps as an Interface), and then use __import__() to load the desired implementation.
That's basically what the plugin system does. At 156 SLOC, it doesn't have room to do much else :).
It seems that without needing adapters, the component architecture doesn't really buy me anything except a formalism (which I do think has value, though limited).
It allows you to use the same language to talk about plugins as you would about any other kind of adapter. Effectively, the plugin system is a way to adapt your "system environment" to an object which provides a given interface. If you use the twisted plugin system (or some other system which uses Interface objects) then it is pretty easy to factor your code such that implementations of the desired interface can be obtained implicitly through the environment or explicitly by user code passing in an implementation -- or by passing in an object that is adaptable to that interface, and then doing adaptation. As Jim Fulton is fond of saying, the whole point of the components system is to allow you to reason about the requirements are for a given bit of code. It also lets you translate that reasoning to code directly. "argument x must be adaptable to IFoo" is a nice succinct way of dictating your requirements both in documentation (by giving a link to the fully-qualified name of IFoo which includes lots more documentation) and in code (by adapting to IFoo, or looking for IFoo plugins, at runtime).
Is this thinking more or less correct? How would people go about doing what I outline above?
Mostly yes. Obviously, I'd personally use twisted.plugin, because that's what I wrote it for :).
participants (2)
-
glyph＠divmod.com -
Terry Jones