[Zope3-dev] Context and Component Lookup

[Jim Fulton]

Martijn Faassen wrote:
> Jim Fulton wrote:
> 
>>>And that makes it clearer that we aren't quite on the same page.  My 
>>>point was that if the "foreign" component does a utility lookup on 
>>>itself, and gets a different result based on who called it, that this 
>>>isn't a good idea. 
>>
>>Right, I understand your point.  My point is that it shouldn't matter
>>because the interactions are through a common interface.
> 
> 
> That doesn't make sense to me. I can have two views, A and B, which
> have the same interface and are associated with the same content
> object interface. But it certainly matters which view is shown.

To whome does it matter?  I suggest that it is often not the code that looks
up the views that cares. The system designer cares.

> What if I have two interfaces that do some storage, one using a relational 
> backend and the other the ZODB? Exact same interfaces but I certainly don't
> want to switch from one to the other just like that.

Why? What difference does it make. The client of those interfaces shouldn't
care.  If the client's do care, there's a problem with the interfaces.

OTOH, parties assembling a system may care very much which components are
used, but these preferences are expressed in the site configuration, not
in the component code.

> Interfaces make code more flexible and it makes it more easy to
> plug in interchangeably, but it doesn't mean that the implementation
> doesn't matter, otherwise you'd only ever need a single implementation
> of an interface...

It generally doesn't matter to the individual components. It does
matter at a higher level.


> [snip]
> 
>>Oh come on. Encapsulation is provided through interfaces.  If a component
>>claims to depend on an interface, but isn't willing to accept alternate
>>components that implement the interface, then *there* is the encapsulation
>>problem.  When we use the component architecture, it's because we *want*
>>to be used with alternative components. All we depend on is the interface.
> 
> 
> But if using an alternate component means I need to *know* which components
> are going to be looked up by that alternate component so I can actually
> supply them in my context, then *that* breaks encapsulation. I shouldn't
> have to know which components are looked up by another component in
> order to use it. It's specified nowhere in the interface. Are you saying
> this should be specified in the interface?  

We need to understand that there are different levels of abstractions.
Interactions between individual components are specified through the interfaces.

To understand how to assemble components, however, you do need more than
the interfaces. There's a book on component-based UML that, unfortunatly, I
can't lay my hands on at the moment. It talks about component specifications.
The component specification talks about both the interfaces provided by a
component *and* the interfaces required by a component.  The component
specification is of interest to the assembler of the components, *not*
the author of them.


...

>>In general, I suggest that components don't and shouldn't care what
>>other components they get hooked up to as long as those components satisfy
>>their contracts.
> 
> 
> What if there's a data dependency?

I don't know what you mean. Any dependencies between infividual components
should be described by the interfaces they interact through.


Jim


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