Common Reuse Principle

The Reuse/Release Equivalency Principle (REP) stresses on the importance of a package (a set of cohesive classes) to be used for releasing reusable software. It also highlights the importance of releasing software that can be tracked, so that the users get a guarantee of interface and behaviour from the author.

However, it is very important to decide which classes should be bound together by a package. Improper selection of classes can create unwanted dependencies and turn usage of that package into a nightmare. Common Reuse Principle (CRP) lays down a good foundation to determine which classes should be packaged together:

The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.

It says that only cohesive classes should be packaged together. As with everything, the packaging of classes and the cohesiveness should be defined from the user’s perspective. If a user uses a package, all the classes in that package should be reusable in the same context. A rule that can be a derivative of this is that all the classes related to a functionality should be packaged together. For example, if I am using a package for matrix calculations, it better have only those classes related to matrices and not trigonometric functions.

As specified by Reuse/Release Equivalency Principle (REP), even if one or two classes are being used, the granularity to be considered is the entire package. This dependency means that with every revision or release of that package, the software has to be tested and revalidated, irrespective of whether the modified class is being used or not. Hence, only those classes should be packaged together which will be reused together.

Back to Design Principles.

Technorati tags: common reuse principle, crp, design principles, object oriented

Copyright Abhijit Nadgouda.