commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Dever" <>
Subject RE: [httpclient] Is the HttpMethod interface a "Good Thing"?
Date Mon, 09 Sep 2002 18:43:09 GMT

I had prepared a point-by-point rebuke, but there was one point that I could
not refute.  One thing that you mentioned is "suppose I want to build ... a
footprint-sensitive version of HttpClient".  This is a situation where an
interface is superior because you don't get all the data members of an
abstract base class.

Let me restate the problem that I'm proposing to fix by converting
HttpMethod into an abstract base class:

	If we have to add a new method to HttpMethod 
	(which we have done several times over the past 
	couple months) it breaks any client code that has 
	implemented the HttpMethod interface.

Whats an alternative solution?

> -----Original Message-----
> From: Waldhoff, Rodney []
> Sent: Monday, September 09, 2002 11:34 AM
> To: Jakarta Commons Developers List
> Subject: RE: [httpclient] Is the HttpMethod interface a "Good Thing"?
> > Comments?
> I think the HttpMethod interface is useful. Consider:
> 1) IMO, HttpMethod is *the* central concept in HttpClient.  
> Everything else revolves around this concept.  Having the 
> (pure) interface helps to document and define that.
> 2) The HttpMethod interface, as distinct from HttpMethodBase, 
> helps to distinguish the "external" interface of HttpClient 
> from the "internal" interface used between HttpMethodBase and 
> its children.  I.e., many of the methods in HttpClientBase 
> are implementation-driven--determined by the way in which 
> HttpMethodBase and its children interact.  The methods of 
> HttpMethod should define a generic interface to be used by 
> Http[Multi]Client and the like.  Having the interface more or 
> less forces the developer to respect this distinction.  Not 
> having it makes it easy to blur the distinction, perhaps 
> without realizing it.
> 3) Extensions to HttpClient are likely to do one or both of 
> the following:
> a) add new HttpMethod implementations (e.g., supporting 
> WebDAV or other RPC-over-HTTP protocols)
> b) add new "clients" that use HttpMethod implementations
> The current HttpMethodBase implementation is intended to meet 
> a variety of client needs--supporting various levels of 
> exposure to the underlying wire-level protocol, various 
> levels of standards compliance and enforcement, etc.  While I 
> think it does an admirable job playing this role, this of 
> course means HttpMethodBase is a compromise.  IMO it is naive 
> to think that HttpMethodBase can be all things to all people. 
>  I can easily imagine alternative forces pulling one toward 
> an alternative implementation of HttpMethod--suppose I want 
> to build a JMeter-style load generator/performance tester, or 
> a footprint-sensitive version of HttpClient for use in 
> embedded contexts, or an HTTP-over-something-else 
> implementation.  Having the interface means I can do all this 
> while being fully interoperable with other clients and other 
> methods.  For that matter, I can imagine a major refactoring 
> of HttpMethodBase that dramatically changes the way it and 
> its subclasses interact.  Having the interface means I can do 
> this without breaking compatibility--I can even use the "new" 
> and "old" style HttpMethods at the same time.
> Both of these types of extension rely heavily upon the 
> HttpMethod interface.  One could make them rely heavily on 
> the (renamed) HttpMethodBase class, but then it becomes 
> substantially more difficult to add the interface later--most 
> clients will have been developed expecting HttpMethodBase, so 
> alternative Method implementations wouldn't interoperate with 
> the most client implementations.
> Leaving the interface around seems mostly harmless.  Taking 
> it out seems potentially quite harmful.
> > As there is 2000 lines of rfc2616-implementing-code in
> > HttpMethodBase, 
> Perhaps that's a good place to focus a refactoring.  For 
> example, let's factor out some of that implementation code 
> into generic utility methods that could be used outside of 
> HttpMethodBase.  That way I could create, for example, a 
> performance tuned load generator (but one that isn't bothered 
> by requiring strict HTTP compliance), without being forced to 
> recreate all of that http managing code.
> (By the way, while 2000 lines probably implies a "big class" 
> code smell, it's not so large an amount of code that its 
> inconceivable that one may simply re-implement that functionality.)
> --
> To unsubscribe, e-mail:   
> <>
> For additional commands, e-mail: 
> <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message