etnu wrote: > Now that we're up to 7 parameters on this constructor, can we accept that > making everything an HttpFetcher is not the best design choice we've ever > made? :) This is especially bad since only two of these parameters vary per > invocation. This is extremely confusing code to follow, and could be much > better written as a singleton with an inner class for request handling.
... which would move the code from using an OAuthFetcherFactory and an OAuthFetcher to using OAuthFetcher and an inner class. You still have two classes, and the two classes need to implement the exact same logic. It doesn't make things simpler, it just moves complexity. About the number of parameters that will vary: nextFetcher, params, and authToken are all reasonable things to vary per-request. The rest are there for dependency injection. We could use Guice for them, I suspect.
