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.


Zope3-dev mailing list

Reply via email to