On 4/13/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>
>
> E.g. currently HttpRequestContext has methods associated with a
> request and HttpResponseContext has methods associated with a
> response. Would merging those two classes into one make really things
> simpler ?
I think before we start talking about which approach is simpler, we should
try and decide what is really NEEDED, and this should be driven by specific
usage scenarios. We can model everything in HTTP just because it exists
(whether we expose it as one or many artifacts), but I dont think that will
serve the API well.
For one thing, I have not yet heard a concrete use case as to why we need an
HttpRequestContext in addition to the metadata injection via method
parameters. Or why Representation<T> doesnt encapsulate metadata returned in
the response. Is this the 20/80 facilitator? If so I'd worry about later.
I'm not yet convinced that it would.
>
> Similarly for HttpResponse and its subclasses. Each subclass is an
> abstraction for a certain kind of response like a temporary redirect.
These subclasses should definitely not be exposed to an app directly. Afaia
concerned these are implementations of specific usage scenarios--not generic
programming interfaces. If you want to provide a utility, then it should be
as a static factory (similar to j.u.Collections as Ive said elsewhere),
otherwise there really will be a class explosion (what happens when new
types of response abstractions are introduced?)
Imagine if we had a public class for each of the utility Executors in j.u.c!