On 7/13/11 9:05 PM, Greg Sterijevski wrote: > Phil, > > "Fortunately for users, maybe less fortunately for developers, we > can't really "evolve" our API rapidly .... This is why we > favor abstract classes over interfaces." > > Just so that I am sure I understand, let me restate the objection to an > interface. An interface approach is more likely to be used broadly, so any > changes which might be made would have a disproportionately large impact. Is > this correct?
No, our rule is we make incompatible changes only in major releases. See [1]. Changes to interfaces are incompatible changes, so whatever interfaces we define we have to be prepared to live with until the next major release. We have no way of telling who is using what or how, so our rules are expressed simply in terms of source and binary compatibility. Abstract classes can add (non-abstract) methods without breaking compatibility. That is why we favor them where possible over interfaces. > > Isn't this a bit of a punt? On the surface the user gets a guarantee, but > the guarantee is a deadend. If we decide a different approach is warranted, > the object is deprecated and ditched at some point. More importantly, if it > is a successful interface isn't that a good thing? > If it makes its way into > a lot of other code, then I doubt we will need to make many changes. Also, I > foresee a two track evolution of features. The interface defines the basic, > most limited set of functionality. Everything else is throw into abstract > and concrete implementations. When a functionality seems to exist in most > derived classes, then the debate should commence about its inclusion in the > regression interface. The evolution would most likely be new features in, as > opposed to current features cut out. There would be a lag of probably a year > in moving a new feature up the inheritance structure to the interface. Maybe > your experience is different. I could be wrong about user demands... What it comes down to is being certain that the core material that we put into the interface is not going to change. Our experience in Commons has been that that is often very hard to do and in most cases abstract classes will serve the same purpose without imposing the same kind of constraints. The evolution you describe above is natural and bound to happen. Trying to avoid interfaces gives us more flexibility in timing, enabling innovative change between major releases. Phil [1] http://commons.apache.org/releases/versioning.html > > Thanks, > > -Greg > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
