begin quoting Andrew Lentvorski as of Tue, May 23, 2006 at 02:15:56PM -0700: [snip] > Java prefers Queue on the theory that you can change the underlying > implementation (LinkedList). I'm with Scott Meyers (see Effective STL) > that this is a red herring. You normally need guarantees about > performance and complexity (big O() notation) that preclude changing the > underlying data structure anyway.
Hm... I'm strongly inclined to go the other direction on this, as I've used the ability to swap out (or proxy) implemenations behind an interface to prove a correctness error. (With refactoring tools that can be done almost as fast, but then I'm changing a lot more code, and there may be "rich features" that get in the way.) Performance issues based on implementations of an interface are best, I thought, left until the profiler has been run. Trust the profiler. (Then again, if you need guarantees, you're looking at realtime programming, no?) [snip] > "The usage of design patterns indicates a language failure." > > I forget where I heard it, but I am now convinced of this. If I have to > use patterns, I am in the wrong language. Hm. Hmmmm. I like design patterns in that they provide a vocabulary. I've always been a bit leery about using 'em as recipes, or as a _guide_ to design. (The most important feature of a design pattern, aside from the name, is the list of tradeoffs: what you give up.) Now the whole topic has been called into question. I'll want to mull this one over for awhile, I think. [chop] -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
