Re: Separation of API and implementation
- From: "Daniel T." <daniel_t@xxxxxxxxxxxxx>
- Date: Wed, 15 Aug 2007 17:11:27 -0400
"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote:
Daniel T. wrote:
In the zoo metaphor above lies the answer to a proper design. However,
since we are talking about programs and not zoos, we have a few extra
resources available to us. Think of the six ways X can acquire a Y to
use:
1) X can create a Y inside 'foo'
2) X can create its Y as a contained object
3) X can be given its Y as a parameter of 'foo'
4) X can be handed a Y though some other method
5) X can use a global Y
6) X can ask a third party for its Y
Objection. Bringing the context in changes little if nothing. In fact, you
replace double-dispatching
foo : X x Y, with
again double-dispatching
foo : X x Context,
here Y is somehow deduced from the context. What changes?
The problem is not in who determines Y, as long it is not X. I.e. the
problem is in which relation are X and Y in foo. If Y is fully independent
or else can be evaluated from X, only then it can be handled by single
dispatch. The former is class-wide Y, the latter is no Y parameter at all.
I fully agree.
If a particular sub-class of X will only work with a particular subclass
of Y, then this needs to be made explicit in the code. Note, even a
double dispatch system doesn't help if it is an error to connect certain
Xs with certain Ys.
.
- Follow-Ups:
- Re: Separation of API and implementation
- From: Dmitry A. Kazakov
- Re: Separation of API and implementation
- References:
- Separation of API and implementation
- From: hforco2
- Re: Separation of API and implementation
- From: Daniel T.
- Re: Separation of API and implementation
- From: Dmitry A. Kazakov
- Separation of API and implementation
- Prev by Date: Re: Separation of API and implementation
- Next by Date: Re: Separation of API and implementation
- Previous by thread: Re: Separation of API and implementation
- Next by thread: Re: Separation of API and implementation
- Index(es):
Relevant Pages
|