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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
