Reusability is much talked about in the world of software engineering and principles. This blog post intends to, define the term and refine the approach with fresh perspective, hopefully!
Heuristic Rules:
1. At a technical dimension, applications that make an attempt to delineate pieces of code /classes/modules/packages in that order, whose usability overlap across multiple systems, and there by eliminate duplication of code across the systems and subsystems, can be described as proponent of reusability.
2. Reusable systems should contain the spread/surface of impact and be cohesive or decoupled. The reason is, this will punctuate the changes within the reusable subsystems down the line and avoid unnecessary changes in dependent systems.
3. Taking this one notch up, at a business dimension, one needs to identify the common aspect of the functional requirements that will overlap with future systems and that recurs through various stages of the evolution of products. Dividing the abstract top layers into downstream sub structures or modules is the pivotal step. As Bertrand Meyer mentions (paraphrased) “The idea is to build modules and subsequent components into brick or box like fundamental atomic units and give life to larger structure using the same” [1]. The goal is in practicality unachievable but that’s the sublime intention.
4. The cardinal rule is decomposition of systems to the point that allows one to extract reusable subsystems.
5. Convenience methods or Utility pattern, allow one to reuse pieces of code across modules and applications.
[1] Object Oriented Software Construction by Bertrand Meyer. – “This criterion reflects an old dream: transforming the software design process into a construction box activity, so that we would build programs by combining standard prefabricated elements”
Design Nutcracker 