durusmail: quixote-users: Re: [slightly OT] Component frameworks and Inversion of Control Pattern
is anyone working ona task list, bug list, issue tracking type utility
2004-08-17
2004-08-17
2004-08-18
is anyone working ona task list, bug list, issue tracking type utility
2004-08-18
is anyone working ona task list, bug list, issue tracking type utility
2004-08-18
Re: is anyone working ona task list, bug list, issue tracking type utility
2004-08-19
Re: is anyone working ona task list, bug list, issue tracking type utility
2004-08-19
Re: is anyone working ona task list, bug list, issue tracking type utility
2004-08-19
is anyone working ona task list, bug list, issue tracking type utility
2004-08-18
2004-08-18
is anyone working ona task list, bug list, issue tracking type utility
2004-08-18
2004-08-20
2004-08-20
[slightly OT] Component frameworks and Inversion of Control Pattern
2004-08-23
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
2004-08-24
2004-08-24
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
2004-08-24
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
2004-08-25
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
2004-08-25
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
Re: [slightly OT] Component frameworks and Inversion of Control Pattern
Shalabh Chaturvedi
2004-08-25
> Graham Fawcett wrote:
>>     * but the interface is the truer decoupling point, since an
>>       implementation that cannot be derived from the schema could be
>>       substituted if necessary (as I suspect in the RDBMS/LDAP case, for
>>       example).

Shalabh Chaturvedi wrote:
>
> I would say the schema is the truer decoupling point. And a schema that
> cannot be built from configuring an existing data provider may need a new
> provider implementation.
>

Hmm.. I read your points again and this time it sounded more like your and
my understanding is similar :) Let me say that the interface is indeed the
*physical* decoupling point. After all, in code, only the interface can be
a decoupling point. All data providers have the same interface - this
interface is fixed and does not change with the schema. Well, on second
thought, the attribute names would change but not any method names.
Depends on what exactly the definition of interface covers. The schema is
the structure of data required, so to achieve true decoupling, an
application says "I require this standard interface *and* this specific
schema". Any provider that provides the schema-specific version of the
interface can be connected to the application.

Whew! Hopefully code will express this more clearly :)

--
Shalabh




reply