There are some more issues, I think, with approaching it this way (e.g. UnsupportedOperationException defers API contract problems to runtime, which could be bad), but I bow to practice, and also don't feel strongly about it.
Instead let me just state the underlying principles that I think we agree on, and if adhered to, will lead us to design software without problems: 1. Not everything needs to be extensible. "Recommender" is obviously built to be extended. "Integer" is plainly not. So I'd just suggest we not try to plan for extension unless there's a plausible case for it. 2. If extension is allowed, it must be on puropse and design for. Making a class robust in the face of subclasses is not trivial and doesn't happen automatically. In my head there is more risk of breakage for extenders here, than just breaking compile-time contracts. The bugs are subtler. And once you figure out someone extended something in a slightly unexpected way, and need to support it, you get locked in to an unspoken 'API' you didn't intend. This can be accomplished with good design with any reasonable approach, and that's all I really care about. On Thu, Nov 26, 2009 at 2:07 PM, Grant Ingersoll <gsing...@apache.org> wrote: > > On Nov 25, 2009, at 8:12 PM, Ted Dunning wrote: > >> Practically speaking, the huge advantage of the abstract class is that you >> have lower update requirements and less duplicated code when augmenting the >> interface. Yes, you can do the dual thing, but the practical experience >> with Hadoop and Lucene has been that using just the abstract class which is >> named as if it were an interface works about better in the long run. The >> update requirements become very onerous when you are dealing with more than >> one package that have to be updated (and which can't for some reason be >> updated simultaneously). >> >> When adding methods, the standard practice is to add an implementation that >> throws UnsupportedOperationException or something similar. Yes, you can do >> this with interace+abstract if *everybody* codes just the right way, but >> with the abstract only approach, there is one less thing for people to do >> wrong. >> >> I took a long time to come around to this pattern of coding, but I finally >> agree that publishing abstract classes really is better except where you >> have to have an interface (for RPC or multiple inheritance). It only takes >> a little bit of outside coding to run into the problem and the social cost >> can be enormous. >> > > Well said. It took me a long time too although I do think you can get > interfaces right if they are kept small. And I think it really is hammered > home by working on open libraries (as opposed to even open applications and > especially to closed source) where you never know where the next good idea is > coming from. > > At any rate, I'm not overly concerned about it just yet. Once the Colt stuff > solidifies, we will have a much better idea of what it needs to be.
