Because when someone else has to learn how your system works, when they start out, they will be thinking about what it does from a user’s perspective, because that’s all (at that stage) they’ve got. Not from a programmer’s, and especially not from yours.
And if they have to learn a bunch of abstract class hierarchies before they can begin to get their head around it – even if those abstractions are well established and are in textbooks and such, and are all nice and neat and by the book, which, let’s face it, they probably won’t be – they will hate you, and curse you and your descendants.
I’m just finishing a project involving the porting and maintenance of a largish, fragile and buggy system, written six years ago in heavily Java-accented Perl. Though I can’t swear that I’ve looked at every class in the app, I’ve looked at most of them, and I have found exactly one family of classes which models a concept which I could explain to a user of the system.
That concept is ‘a report’. Typically for this code, the family of classes is not called X::Y::Z::Report, but X::Y::Z::Sort, and tracing the inheritance relationships is a nightmare. So it’s not like modelling business concepts is going to make you write good code, but it avoids whole constellations and galaxies of ways of writing bad and misleading code.
