Yes I see that now..missed that. I do this all the time...so sure would like to know if there is a better way.
-Dave On Fri, Feb 22, 2013 at 8:04 AM, Bram <[email protected]> wrote: > Yes, that was my intention (as you can see at the Impl naming of > HttpClientFactoryImpl). > > Op vrijdag 22 februari 2013 14:47:17 UTC+1 schreef dhoffer het volgende: >> >> How about also extracting an interface for HttpClientFactoryImpl and let >> WebCrawler be >> injected (by Guice) with that interface? I prefer objects to only know >> about interfaces of their collaborators. >> >> -Dave >> >> >> On Fri, Feb 22, 2013 at 6:32 AM, Bram <[email protected]> wrote: >> >>> Thanks for your answers. Would it be possible (and advised?) to >>> implement my own factory logic for, for instance, a HttpClient? I still >>> have a hard time accepting that my WebCrawler has to depend on a connection >>> factory, it doesn't make sense to me (but maby im wrong). (the webcrawler >>> is just an example to keep it simple btw, my own code is pretty domain >>> specific). >>> >>> If I would implement my own factory for the HttpClient it would look >>> something like this: >>> >>> public class HttpClientFactoryImpl { >>> public HttpClient createClient(Uri uri) { >>> Connection conn = connectionFactory.create(uri.**getHost(), >>> uri.getPort()); >>> return new HttpClientImpl(conn); >>> } >>> } >>> >>> If my factory would look like that, a webcrawler can only depend on the >>> HttpClientFactory. That factory is, in my opinion, the onwly factory it >>> should depend on. Wy would a webcrawler "know" how to create a connection >>> object? A webcrawler would then look something like this >>> >>> class WebCrawler { >>> private final HttpClientFactory httpClientFactory; >>> >>> public WebCrawler(HttpClientFactory httpFactory) {...} >>> >>> public crawlDataFrom(Uri uri) { >>> HttpClient client = httpClientFactory.**createClient(uri); >>> client.doMagicStuff(); >>> } >>> } >>> >>> >>> Is something like this possible? Is this "better" or bad-practise? I >>> want to prevent creating god-like classes that know allot and/or depend on >>> allot. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "google-guice" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to google-guice...@**googlegroups.com. >>> To post to this group, send email to [email protected]. >>> >>> Visit this group at >>> http://groups.google.com/**group/google-guice?hl=en<http://groups.google.com/group/google-guice?hl=en> >>> . >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >>> >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/google-guice?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
