OnReuse

There seem to be two intuitions :

1) You can design for general flexible re-use. By making things more modular. And maybe smaller modules? (BangTheRocksTogether)

In OO programming terms we could call this the FrameworkStrategy. Large frameworks of lots of little interdependent classes.

2) You can't design for general re-use. You hit the NoFreeLunch problem. Anything that improves one kind of re-use, potentially makes another more difficult. So you can buy flexibility with the FrameworkStrategy but at the cost of a steeper learning curve and more complex management of the different modules.

Sometimes you want the alternative, a ComponentLibraryStrategy, with larger, more independent, less flexible but quick to get going with, modules.

Maybe the component / framework dichotomy is too simple, and it's really a question of getting the right granularity of components. See GranularityMistake.

See also :

• TheLibraryProgramBoundary

• ObjectOrientedProgramming and DoesAbstractionScale

• This is another TradeOff

• FractalLoading

CategoryDesign