The Myth of Software Reuse gives you the following claims
I have a Gameboy ~~ 10 years.
A bike ~~ 7 years.
A watch ~~ 12 years.
Each of them has good cheaply available parts which can be used for
It is on the success of Engineering, Software Engineers make the
claims of reuse.
Sadly most claims remain more exaggerated than true.
For example, the Factory Pattern doesn’t have the notion of pipelines
and yet it is supposed to help us somehow into making the “car” objects.
Can we be inspired by Engineering to do better ?
Engineering products typically have series and each series typically has generations.
For a car company, we can imagine a A series and a B series.
Firstly A and B can be so different, the only thing common between them is primitives
and designs ideas.
For Software this is,
For A and B, the manufacturing pipeline can be common.
Between A and B
Old components can be
The maximum reuse happen at Primitives, Data Structures …
Important reuse goes into to Architectural/Design Patterns.
For flexible UI, create common and flexible Interfaces.
The most ignored is the “Module Set”.
With the help of such a set we get easy Build Steps and Internal reuses.
What is a Module ?
A Module has
To create a Module Set is a Creative Process.
** It is a skill, not a framework **
The Set can be divided into two aspects.
Data Flow and Control Flow.
Data Flow is made up of Data Paths and Transformations.
Control Flow represents
Steps and Transformations are easy to Modularise.
Sequencing can be modularized with the help of decision trees.
To reuse, just stick to off-the-shelf
Each should however be implementable by-hand, when absent as a library.
In fact the library should not be different from a hypothetical implementation by-hand.
Any fluff just muddles the pure Design Concepts.
Learn Module Decomposition.
A litmus test for a programmer understanding modularity
is whether he can implement a plugin system.