The idea of ‘designing for extensibility/change’ merges the two things. And it cannot be correct or possible in general.
An example is describing the ‘open-closed principle’ (‘Object-Oriented Software Construction’; Meyer; 1997. s3.1 p40) as: “In other words, (in an ideal world...) you should never need to change existing code or classes: All new functionality can be added by adding new subclasses or methods, or by reusing existing code through delegation.” (http://c2.com/cgi/wiki?OpenClosedPrinciple)
This implies we should be aiming to avoid changing things, that software engineering is or should be ‘striving for exstensibility’ – pre-planned extensibility. This cannot really work.
The very act of designing something creates the possibility of its needing to be changed. If you design an abstraction, you have made some room for change – in the varying part of the abstraction. But you have also, necessarily, defined something as fixed that resists change.
Reuse is really just use – it does not require some special kind of abstraction or design. It is just design for a set of users that are more spread out in space or time.
The problem of designing for ‘reuse’ is really the same problem as any design: if you cannot get good information on what is required, you cannot make a good design, one that will be useful. The problem of designing for ‘reuse’ is we cannot get good info – partly because we cannot predict the future. The problem of designing for ‘reuse’ is knowing what is likely to be wanted, not really of how to build it.
The hard problem of reuse is of what not how. It is about knowing what will be needed. That cannot be solved with language/programming/technical means.
* * *
But you could say we can predict probabilistically: we can build a picture of what requirements have what probability of being needed. And therefore that we can benefit from particular technical means to represent that particular kind of probabilistic picture.
That seems to contradict the thesis, but it is actually just saying the same thing. Do we have that probabilistic data, that probabilistic picture? If we do, we have the info of what is to be built. There is something solid that an abstraction can be designed for – that its fixed part can represent. So we are back where we were. A probabilistic picture is just another kind of knowledge.
Abstraction is a way of handling multiple things as one thing. Multiple ‘tokens’ are represented/encompassed/grasped by one ‘type’ – in philosophical terminology. (Ultimately, this is good because it lets us do multiple pieces of work (understanding, production, etc.) with a single piece of effort. Abstraction is like the basic force-multiplier of the information realm.)
But the relation between ‘tokens’ – instances of an abstraction – is not really that of change. (Just because instances occur at different times does not make the situation one of change.) If a change fits as a new instance, either you are just lucky – which is not a sensible, reliable way of working in general, or you planned it – in which case it is not really a change in a strong sense.
We want to address hard change, change you do not expect. Designing abstractions by thinking ahead cannot do that. Change is handled by thinking about what you know now: the abstractions you have, those you need, and how to go from one to the other.