Split or Join

Aim for the structure with the best information hiding, the fewest dependencies, and the deepest interfaces. Splitting has costs of its own: more interfaces, glue code, distance between related code, and duplication. Length alone is never a reason to split.

Join when

• They share information. Both know the same format, protocol, or rule. Reading and parsing an HTTP request are one example.
• Joining simplifies the interface. The intermediate hand-off disappears, or a feature becomes automatic. Example: buffering built into file input instead of a separate class.
• It removes duplication. Factor out repeated code, or restructure so the snippet runs in only one place.
• They're conjoined. You can't understand one without reading the other. That is a split gone wrong.
• They were split by time order (read, then modify, then write) but share knowledge. That is temporal decomposition. Group by knowledge, not sequence.
• They're used together in both directions. A one-way relationship doesn't count: a block cache uses a hash table, but a hash table stands alone.

Split when

• General and special-purpose code are mixed. The mechanism keeps the general part, and the use-specific code moves up to the caller or down into plug-ins. Example: History handles generic undo, while each text or selection action implements its own undo.
• The pieces are truly independent. Readers can focus on one at a time without flipping back and forth.

Splitting a method