Re: Use Builder pattern ( was: Re: Http client API)
On 09/08/12 10:50, Chris Hegarty wrote: On 09/08/12 00:00, Jed Wesley-Smith wrote: Michael McMahon michael.x.mcmahon@... writes: A new revision of the Http client API planned for jdk 8 can be viewed at the following link http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ We would like to review the api on this mailing list. So, all comments are welcome. Can you separate the domain objects (in particular HttpClient, HttpRequest) and their set-up (all the mutators) into separate concerns (Builders perhaps, see Guava for instance)? +1, I agree with your comment. Wherever possible we should try to use a builder pattern to build immutable objects ( or limit its mutability as much as possible ). I think Mike made a very similar comment too. Maybe the spi and factory/builder could be separated out, I think this would be much cleaner. As you say, you get thread-safety by default, which would appear to be a nice property for this API, given its different programming models. I agree. The various mutable set() type methods should be in builders and the resulting HttpClient and HttpRequests should be immutable. Will look into that now. Thanks, Michael.
Use Builder pattern ( was: Re: Http client API)
On 09/08/12 00:00, Jed Wesley-Smith wrote: Michael McMahon michael.x.mcmahon@... writes: A new revision of the Http client API planned for jdk 8 can be viewed at the following link http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ We would like to review the api on this mailing list. So, all comments are welcome. Can you separate the domain objects (in particular HttpClient, HttpRequest) and their set-up (all the mutators) into separate concerns (Builders perhaps, see Guava for instance)? +1, I agree with your comment. Wherever possible we should try to use a builder pattern to build immutable objects ( or limit its mutability as much as possible ). I think Mike made a very similar comment too. Maybe the spi and factory/builder could be separated out, I think this would be much cleaner. As you say, you get thread-safety by default, which would appear to be a nice property for this API, given its different programming models. -Chris. It'd be nice to have this all thread-safe by default, it seems creating an API that isn't thread-safe is maybe not ideal. cheers, Jed Wesley-Smith
