archives

Whither actual generality/customizability/flexibility?

I have yet to come across The Answer to being able to really truly do the Open-Closed principle. "I'm sorry, Zaphod, I just don't believe a word of it." Be it OO or FP or whatever, in my experience when a new functionality / requirement / realization comes along, there's nothing that can be done to prevent some inevitable need to crack open the bloody code and have at it.

Random example: Inheritance.

We have all experienced trying to plan ahead for change. Inevitably, when change comes, it is not the change we anticipated. We find that we have paid the price of generality and forward planning, but still have to modify the software to adapt to the change in requirements. Agile methodologies use this: they tell us to eschew generality, and instead make the software ready to embrace change by being changeable. Inheritance aids in this process by allowing us to write software in terms of the concrete, specific actions that the application needs now, and to abstract over them only when we know - because the change request is in our hands - that the abstraction is needed.

Except for how I haven't seen inheritance ever done right, such that there really isn't long term peril and sturm und drang that is going to come along with it, ball and chain style.

If you had to force rank the various ways people have tried to support something like Open-Closed, what would your list look like?