Odi, (1) The DI pattern does not imply the use of a container. So, I am not sure why you find it complex.
(2) Object factory by itself does not solve the problem: the factory must be able to 'discover' its impl (SL pattern) or there must be a way to 'inject' the desired factory impl (DI pattern). We are back to the same dilemma (3) Subclassing is certainly a feasible solution. However, consider the following case: all you want is to replace the default HttpDataReceiver in order to implement an application specific HTTP line parser. Then if there is no way to discover or inject your specific impl, you also would have to sublcass the DefaultHttpClientConnection to make it use you own impl of HttpDataReceiver. Then you would have to implement a custom connection manager to instantiate custom HTTP connections. While not impossible this is hardly the way you would want to spend your weekend. HttpClient 3.0 already makes use of both patterns: HttpClient/HttpConnectionManager, HttpClient/HttpMethodRetryHandler represent a perfect example of the DI pattern, whereas CookiePolicy/CookieSpec, AuthPolicy/AuthScheme implement the classic SL pattern. We ought to consistently apply the same approach to other cases where users may want to provide a custom impl of a particular HTTP primitive (MyHttpClientConnection, MyCookie, etc) Oleg On Thu, May 19, 2005 at 09:11:36AM +0200, Ortwin Gl?ck wrote: > Oleg, do we need such a complex architecture as DI at all? Any chance it > could be done through factory methods and subclassing? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
