I've never actually done an API vs. IMPL separation in my own work to date. But my initial (probably naive) thought is this:
Doesn't this only matter if the "impl" is supposed to be pluggable? If the "impl" is not pluggable, then there are only two advantages of the api/impl separation: #1. It's a nice way to communicate to the consumers of the library the methods that are there explicitly for them! The "official" entry-points into the library are easier to discern. #2. (That age-old saw:) Makes for cleaner code that is easier to maintain. So to me, if the IMPL isn't pluggable, then a small number of dependencies is okay if it makes the library easier to use. yours, Julius On Fri, 2007-02-02 at 18:44 +0100, Roland Weber wrote: > Hi folks, > > I just noticed that we have dependencies from API classes > to implementation classes. The one I stumbled across is > AbstractHttpMessage, which depends on DefaultHttpParams. > > Is there a consensus that the API classes and interfaces > should never depend on any implementation package? > > cheers, > Roland > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Julius Davies, Senior Application Developer, Product Development T 416-652-0183 | [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
