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”
No comments:
Post a Comment