commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tobr...@transolutions.net (O'brien, Tim)
Subject RE: [codec] RE: Base64.java
Date Tue, 04 Feb 2003 19:04:47 GMT
You example below would make sense if the Base64 implementations were
dramatically different.  It should be noted that the only sticking point is
chunked encoding - in essence, XML-RPC needs an implementation that adds
"\n" every 76 characters, and HttpClient does not.  Making two different
implementation classes in this case might be overkill.

--------
Tim O'Brien

> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com] 
> Sent: Tuesday, February 04, 2003 12:56 PM
> To: Jakarta Commons Developers List
> Cc: tobrien@transolutions.net; 'Jeffrey Dever'; rhoegg
> Subject: Re: [codec] RE: Base64.java
> 
> 
> 
> The concept of setting flags etc seems to be quite poor OO. 
> Maybe I'm not understanding things properly though.
> 
> Shouldn't it be a classic FactoryMethod pattern?
> 
> Base64Utils
> Base64 interface
> 
> hidden classes:
> 
> RFCBase64
> OtherBase64
> JimsBase64
> 
> and then:
> 
> 
> Base64Utils->
> 
> public static Base64 RFCBase64 = new RFCBase64().
> ...etc..
> 
> ??
> 
> Hen
> 
> 
> On Tue, 4 Feb 2003, Martin Redington wrote:
> 
> >
> > Hi all,
> >
> >      personally I favour Ryan's suggestion of setting flags (and/or 
> > system properties) separately to obtain non-RFC compliant behaviour 
> > (or to specify which RFC to follow, where they conflict), or to 
> > specify that exceptions should be raised when encountering a 
> > non-Base64 char, rather than adding additional args to method 
> > signatures.
> >
> > Given the wide usage of this code, and the need to inter-operate 
> > smoothly with other implementations that may or may not 
> comply with a 
> > particular RFC, giving the end-user as much flexibility as 
> possible is 
> > probably a good thing and shouldn't add too much complexity to the 
> > code. Maybe both approaches would be appropriate.
> >
> >     cheers,
> >            m.
> >
> > >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message