Hey,
Resolving redirects and retrieving entities are two different things.
Sometimes you want to do both, sometimes just one. Trying to create a
general solution by adding one of them to an existing interface dedicated
to the other is bound to end up being problematic, as your email
illustrates. I suggest only putting them together where there is need to do
so, and create new objects and interfaces based on the needs encountered
there. Forcing the existing interface to know about redirects would be
repeating the mistake of putting the revision id in there, though in this
case it'd be worse.
Perhaps we can get around all this mess by making redirect resolution
something
the interface doesn't know about? An implementation detail? The logic for
resolving redirects could be implemented in a Proxy/Wrapper that would
implement
EntityRevisionLookup (and thus also EntityLookup). The logic would have to
be
implemented only once, in one implementation class, that could be wrapped
around
any other implementation.
From the implementation's point of view, this is a lot more elegant, and
removes
all the issues of how to fit the flag for redirect resolution into the
method
signatures.
However, this means that the caller does not have control over whether
redirects
are resolved or not. It would then be the responsibility of bootstrap code
to
provide an instances that does, or doesn't, do redirect resolution to the
appropriate places. That's impractical, since the decisions whether
redirects
should be resolved may be dynamic (e.g. depend on a parameter in an web API
call), or the caller may wish to handle redirects explicitly, by first
looking
up without redirect, and then with redirect resolution, after some special
treatment.
I'm not suggesting this is the approach to take, though I disagree with the
objections raised against it. First of all, it is not the caller that has
the control, it is the thing configuring the object graph being used. If
the decision if redirects should be resolved or not needs to happen after
this configuration, then you can simply have your object require both types
of lookups. This would work, though it makes clear the approach of putting
this functionality in a wrapper is odd for this use case. Having a service
to resolve redirects and one to look up entities would be a lot more
natural.
Cheers
--
Jeroen De Dauw -
http://www.bn2vs.com
Software craftsmanship advocate
Evil software architect at Wikimedia Germany
~=[,,_,,]:3