On Nov 19, 2007 3:35 PM, Jerome Louvel <[EMAIL PROTECTED]> wrote: > > Hi Chuck, > > > Jerome, I know you've made this statement before (interfaces in public > > APIs), and since it is your project, I've not pressed you about it, > > but I'd still like to see some evidence that this is more than just > > personal opinion. > > Initially, the API had many interfaces but some (Henry Story I think) > pointed me that public APIs based on interfaces are fragile because once > they are published they can't easily evolve. > > If you have interface A with method A1 in version 1.0, then users will > implement it in their custom classes, this is fine, they can easily mock > them. > > Then, for version 2.0, the need to add method A2 appears and is added to the > A interface. When the API is published, users try to upgrade and realize > that their custom classes don't implement method A2, or implement it with a > different purpose or different arguments. Their code is broken and the API > break the ascendant compatibility. [...] I see the point, but remain unconvinced; with modern refactoring and dependency management tools, I'm not sure that this is an actual problem.
I'd also point out that many people view the addition of a method to a base class (abstract or otherwise) as a breaking change (because existing clients may have already implemented a method with the same signature in existing subclasses). If you change an API, it doesnt seem unreasonable to me to expect that implementors will have to change their implementation. To me, it seems like a case of throwing the baby out with the bath water. Versioning's hard, and there are appropriate and inappropriate uses of interfaces, but to make a blanket statement that interfaces shouldn't be used in a published API seems unwarranted. I was actually hoping for a pointer to a discussion about the pros and cons of using abstract classes instead of the interfaces in published APIs, but I haven't been able to find anything - which makes me wonder whether it's really that big a deal. --Chuck
