October 9, 2007
What Makes Abstractions Less Likely To Change?The received wisdom regarding dependency management in OO and component-based design is that it's better to depend more on abstractions. But I think this might be a bit of a red herring.
Statistically, it's demonstrably better to depend upon modules that are less likely to change. But is a module less likely to change because it's abstract?
Abstractions in code tend to be less likely to change because:
1. They contain less things that can be changed (well, duh!); and...
2. They tend to be reused
The first point is a no-brainer.
The second is a little more subtle, though. The more code is reused, the more corroborated it becomes. We can be more sure that a method, class or package is more widely applicable the more widely it's applied. (Well, double-duh!)
Simply declaring types as abstract classes or interfaces doesn't, by itself, make their code less likely to change, because that would be some sort of voodoo!
So, instead of saying that we should favour "depending upon abstractions", maybe we should argue that it's better to depend upon smaller modules that are reused more?
I feel another experiment coming on. Nurse! The Screens!
Posted 13 years, 10 months ago on October 9, 2007