[Zope3-dev] adaptation based on class rather than interface

[Jim Fulton]

Martijn Faassen wrote:
> Martin Aspeli wrote:
>>
>>
>> Martijn Faassen wrote:
>>> Oh, I disagree. It's much nicer to be able to be able to start with 
>>> adapting classes, and introduce interfaces later, where necessary. 
>>> Often they're not. In fact it's already possible to adapt classes and 
>>> register views for classes. In ZCML I believe there's some 
>>> limitations with one directive or other (a bug), at least there was, 
>>> but the component architecture has allowed this for a long time. 
>>> We've been very happily using this in grok.
>>>
>>
>> I see your point of view - and I guess there is a balance here. 

y'all agree. :)

>> However, I
>> think that one of the big benefits we see in Zope2/CMF/Plone over "the 
>> old
>> way" is that people seem to take interfaces more seriously now, and with
>> them internal documentation. Having well-thought-out and well-documented
>> interfaces encouages API stability and re-use

Yup, assuming that that is a goal.  Sometimes, it isn't.


>> and makes it easier to understand someone else's code.

Likewise. :)

 >> By contrast, we often end up with
>> jungles of
>> APIs and no-one can quite decide whether they're stable or not, when
>> programmers are given no hooks on which to hang their design.

That can happen with interfaces too.

> Yes, but with Plone and CMF and Zope 2 we already have a lot of existing 
> classes, so it makes sense to introduce interfaces: it is more clear 
> what they should be.
> 
> It's a lifecycle thing; early on in a project explicit interfaces may be 
> overkill.  If a project never grows beyond a certain size it might be
> permanent overkill, actually. Later on in a project where extensibility 
> and explicit specification and programming by third parties and so on 
> becomes important interfaces make lots of sense.
> 
>> Do as you wish, of course. I find that abstract discussions like this
>> typically end up being a lot of talk over apparent disagreement that
>> disappears when it comes down to practical design.
> 
> Of course. It's all a matter of tradeoffs. Disagreement does exist in 
> practical design as well though. In particular, the Zope 3 explicit 
> interfaces and components everywhere approach sometimes leads to 
> overengineering where simple Python patterns would've done much better.

Let's please not call this the Zope 3 approach.  As Pope, I officially
declare that the Zope 3 approach is interfaces and components
(and doctests) where appropriate. :)

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org