Granule Of Release

A software GranuleOfRelease (or unit of modularity) is a collection of software with the following attributes:

• Performs, or contributes to, a specific functionality
• All software within the GranuleOfRelease is necessary for completion of that functionality; it would be difficult to use only part of the GranuleOfRelease. (It may be possible for specific such granules; but you shouldn't depend on that).
• May depend on other GranuleOfModularity?s (bad plural, I know); however the dependency graph among UnitsOfModularity? should not contain any cycles. Cycles among classes (etc) within a GranuleOfRelease are generally OK, though they should be short (no more than 2 or 3 participating entities); anything larger indicates that ReFactoring may be necessary.
• The GranuleOfRelease is the granule of reuse - see ReuseReleaseEquivalencePrinciple.

Names given to granules of release in various languages and various works in TheLiterature? include: class, module, package, cabinet, library, component, etc. Unfortunately, this is one area where the terminology could use some harmonization.

The phrase granule of release is chosen to avoid collisions with any of the above.

---

Many practitioners of various languages/paradigms insist that a particular language feature (such as the "class" or "module") is the proper granule of release. Languages which force the GranuleOfRelease to be a particular size usually result in maintenance/configuration headaches. That said, the UnitOfModularity generally shouldn't be smaller than a single class or stand-alone function. (Some languages require the GranuleOfRelease to be a class or first-class object; but allow other classes which do not have this functionality; that's OK. What is objected to is the notion that all classes should be releasable components).

Not to be confused with the GranuleOfDeployment. The GranuleOfRelease should be smaller than the GranuleOfDeployment.