[Zope3-dev] Allowing views to be registered for classes rather than interfaces.

[Martijn Faassen]

Jim Fulton wrote:
> Martijn Faassen wrote:
> >I think it is odd that most interfaces will have only a single 
> >implementation.
> >It shouldn't be that way; I think if something is to have multiple 
> >implementations an interface should be provided, but an interface
> >should not really be necessary if you only ever expect one implementation. 
> 
> I disagree. The interface bounds what users of an implementation can rely
> on.  It says how the clients and the implementation will be hooked up.

I think the desirability of an explicit interface depends on a lot of
tradeoffs:

  * high or low level APIs. A high level API needs an explicit interface
    more than something which is mainly used in the implementation.

  * amount of clients to the API. If there's only a single client expected,
    a solid explicit interface is less necessary.

  * distribution of work. If I expect the client to my code will be
    implemented by someone else, an explicit interface is good 
    documentation. But if I'm prototyping by myself I'll write the client
    myself initially. Similarly, if I expect multiple people to
    implement a particular API, documenting the API is more important than
    if I am going to implement all variations myself (subclassing
    may do just fine for a while).

  * exploration. If I'm implementating a standard API or an API I am
    extremely experienced with, writing an explicit interface is easy.
    If I'm playing around with things, exploring various solutions,
    having to maintain an explicit interface drags me down.

  * stage in development. Sometimes code evolves from a state where it
    is explicitly geared to solve a single solution for a particular
    client. It is deliberately ad-hoc code, as I am aware I don't
    know the various possible requirements enough yet to be able to
    support pluggability. Later on with more experience, it will become more 
    clear which areas of the code need support for increased pluggability, and
    explicit interfaces become established. Any interface which I
    write before that will be *wrong* anyway, and may even be 
    overanticipating requirements which will never arise. Why waste
    time on this; YAGNI.

and I'm sure there are more. 


The point is not that I dislike explicit interfaces; it's great when they're
there if they're good, and I am to use  the code.

The point is that I think they can hamper development under certain
circumstances, and can be discouraging. I suspect I am not the only 
Python programmer who thinks this way; after all we're programming
in Python, not using Java or C++.

> >You can argue a separate interface helps one clarify the structure of the 
> >code, but I don't really buy that; a class with docstrings works just as 
> >well. Having to maintain a separate interface in sync with the class is a
> >bother and reminds me of C++ header files, which is not a good memory. 
> 
> Well, we disagree then.

I hope you will be more specific now that you've seen my more extensive
response. Or are my considerations considered counterproductive at this
stage?

Regards,

Martijn