On Thu, Nov 26, 2009 at 9:27 AM, Sean Owen <sro...@gmail.com> wrote: > 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. >
Absolutely. Commons math tried to plan for extension everywhere and they wound up for great numbers of Interface/Abstract/Implementation/Factory class quadruples for things that are akin to Integer. The result is a nearly unusable mess in certain areas and it certainly is very difficult to understand for a newcomer. 2. If extension is allowed, it must be on puropse and design for. > Yes. > 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. > Yes, yes, yes. > This can be accomplished with good design with any reasonable > approach, and that's all I really care about. > This should be the last word, but I am going to add that I think this is a very important principle that we should all probably repeat at least once a week. I know that I slack off on design in the heat of implementation. I know it is rarely a time-saver and never pleasant to fix. -- Ted Dunning, CTO DeepDyve
