I just sent this bit of promotion for the Zope Component Architecture to a friend (paraphrased slightly):
The Zope community uses adaptation for a new purpose. While adaptation is classically a way to force uncooperative classes to communicate, that is not the intent of the component architecture.
The intent of adapters in Zope is to expand objects’ contracts to fulfill application requirements while not polluting reusable code. Adapters act like a streamlined form of model/view separation.
The community’s experience with Zope 2 was that while we did our best to keep code modular and reusable, there were simply too many cases where we needed to change the behavior of a base component in order to fulfill application requirements. We badly needed a way to use some kind of model/view separation at any point in the code.
Using Zope 2, we tried several industry solutions to address this, but using any of those solutions, we still found that application-specific dependencies had to creep into otherwise reusable code in order to meet reasonable deadlines. That really hurt too, because we were a bunch of hard-core OO developers and we really hated breaking modularity. We knew we were incurring a long term debt.
The Zope component architecture is the little gem that resulted from that long experience. It helps programmers avoid creating application-specific dependencies at every level. The component architecture resembles other indirection frameworks like Spring and AOP, but I believe it solves more problems elegantly.
That said, the Zope community now has enough experience with the component architecture to know that the first time we applied it in Zope 3, we applied too much of it in some places. Thus Zope 3 is currently somewhat overgeneralized. Like any indirection framework, you have to gain some experience before you learn what indirections are appropriate.
How am I doing? I think the ZCA would be quite valuable for my friend, who is today an excellent Java designer and coder. I want to find the right words to express why it would be valuable to him.
I think it’s a pretty good description.
I like it as well.
Hi Shane, I liked it very much. Only, I didn’t understand the nub of it, paragraph two. That could be a good place for an example (if you’re planning to grow this). Also, I would drop the little from “little gem”. It’s a gem. (I think!)
You’re right, I didn’t explain the second paragraph well. I’ll improve it later. 🙂
That’s a good text, Shane.
As a longer explanation of adaptation in terms of models and views this might contain useful text:
http://grok.zope.org/doc/current/grok_overview.html#adapters
If your friend actually would like to use adaptation in Python, it might be interesting to introduce them through grokcore.component, which lets you register adapters using the Zope configuration system without having to write anything else than Python code. (and a 3 line configure.zcml). It’s reusable in plain Python applications without Zope.