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

[Jim Fulton]

Martijn Faassen wrote:
> 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. 

I support the notion that during early stages of development that
it should be possible to work with less formalism.

My point is that the fact that an interface has a single implementation
is not odd. An interface may have one implementation and many clients.

Note that, initially, an interface may only have one client and one
implementation, however, in the interest of *basic* pluggability, like
providing alternate views, an interface is useful.


> 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?

I specifically disagree because I don't think an implementation sufficiently
bounds usage. If I depend on a class, rather than an interface, the author
of the class has to retain all of the methods and their semantics as described
in the doc strings.  If they remove any methods or change the semantics of any
methods, the clients are broken.  An interface, OTOH, provides a more formal
contract.  The class may provide additional methods that it's implementation
finds helpful at a point in time and remove those methods later.

Jim

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