On Sep 7, 2005, at 5:39 PM, MenTaLguY wrote:
It's almost always better to do a straightforward implementation and get it structured appropriately -- and _then_ factor out the appropriate abstractions, than it is to introduce an extra abstraction anticipating a future need.
At first I disagreed with this generalization, but then I realized some details that differentiate what I was thinking of and how it diverges.
* Adding extra abstraction for later -- more often not good.
* Starting with abstraction and implementing behind it.
The latter is what I'd suggest is good. However, the driving force would be in analyzing the base concepts involved and proceeding from there. That is, toss around all the ideas involved, and then boil them down to their pure "thing-ness" that make those things what they are. Then group up in nice modules, and abstract things at the boundaries. Then go in and implement each module.
So it would be the case for abstracting at module boundaries rather than abstracting for possible future need. Of course, when done properly the former can make the latter much easier. Then again abstracting at module boundaries helps reduce spaghetti linkage, improve testability and clarify desgin. So that can go in as an immediate payoff as compared to the "anticipating a future need" guess at payoff.
So I'd probably summarize that as starting with abstraction is good, just as long as it's the proper abstraction. :-)