Re: Abstraction and Detail
Posted: Apr 15, 2003 6:05 AM
[BTW: great site, Bill! Wonderful the calibre of telent you've attracted, too]
I think the point about "experience" is very telling. A lot
of XP is aimed at new programmers (or people programming in new areas they are unfamiliar with). If you don't know what you are doing, you had better not commit to anything prematurely! And in a genuinely new area, that applies to all of us.
For example, on table-driven programming: extracting out such details into a table only makes sense if you know that this view of the problem is correct. A strong hint is if you find you have a bunch of cascading if-else statements *already*. Then, it could make sense to use a table.
Or if you use polymorhpism to get different behaviour
for different contexts... you could convert that to a table, too.
And... maybe you don't have if-else cascade, nor polymorphism, but you can see that you *could* convert it to one of those forms... that is another candidate for table-driven programming.
I've converted to polymorphism a few times... but the resulting code was quite awful, adding a layer of complexity. Too much premature committment to a
particular view of the problem, too. I think tables would be the same - although more flexible in their content, you are still committing to what you think are the invariants.
I can see that if you are programming close to the domain, then your view of the problem probably is going to be correct, and so this commitment is fine. But if you don't have a clear view of the domain (ie defining and understanding the domain is part of the problem), then committing to tables of a particular kind is just adding overhead that (very likely) will have to be thrown out.
I think that these approaches weren't really appropriate to the problems I tried them on. It would be nice to see some concrete examples of where it *is* appropriate.
I get the sense that Andy and Dave have a tremendous amount of experience, and in a number of domains... and so what works for them may not work for others, if they lack this level of domain knowledge and understanding.
The issue is similar to upfront design of modules - unless you understand the problem pretty well already, you really want to avoid committing too much to a particular modularity, and just get one with coding and so maximising your learning about the problem. (Of course it's different if you absolutely have to modularize easrly on, in order to divide up the work).