Not spliff, split.
ReuseSplit is simple.
Getting true reuse takes time, and effort, and thought, but with ReuseSplit, you can achieve a good percentage. It also provides a focus for reuse, where it can grow.
Two (Inter)Faces
"if you are as two faced as momma always says, why do you always wear that ugly one?" - anon
Generalization and Specialization. Split your code out into these two (inter)faces. The Generalization should be contained within a separate project. The Specialization within your current project.
Its not revolutionary, its simple. However, the majority of code in the business looks like Specialization only. Then perhaps what is common, then perhaps something reusable. However, by ReuseSplit, you are immediately doing two very important things. You are splitting what changes from what does not, and you are developing with reuse in mind, which creates separate code for reuse later, which means you are developing malleability into your solution as well.
Generalized
When we say, lets create a "Generic" something, we mean something that is versatile, more or less common, more or less reusable, more or less specialized.
By generalizing, we convert, "The quick brown fox jumps over the lazy dog", to "the (adj) animal jumps over the (adj) animal".
Now we know we need two instances of an Animal class, and some descriptive attributes that can be applied to the Animal.
This does not mean inheritance, it could be implemented in any sort of way, its the separation of Animal and Fox that is key.
Specialization
If you need a specific Fox, then build one, using the Animal, whether by composition or inheritance. The Specialization then feeds the Generalization. If it is common move it down.
By using this technique, thinking about ReuseSplit with everything I do, I like to think that I make an extra 10% of reuse on code, without thinking. Like driving a car, I don't think about it as I am doing it, however, reuse is usually higher, when I hit a project.
Tags: design, frameworks, design pattern, reuse