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

[Martijn Faassen]

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. 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 and makes it easier to
> understand someone else's code. 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.

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.

Regards,

Martijn