Tutorials : Designing Packages for Stability :

Stable Abstraction Principle (SAP)

Stables packages should be abstract packages. The instable packages should be concrete. The abstraction of a package should be in proportion with its stability.

Following SDP, it means that the less stable packages would reside atop a package hierarchy and the more stable packages reside at the bottom of the package hierarchy. Thus, it becomes extremely important that the classes in the stable packages become resilient as they have more change-impact on the system.

The SAP dictates that the stable packages should also be abstract so that its stability does not prevent it from being extended. On the other hand, the instable packages can contain concrete code as its instability factor makes it easier to change the concrete implementation. This also resembles the Open-Closed Principle regarding the class design where it is advised to depend upon the abstraction rather than the implementation. The SAP further extends the same principle to package design. It says that the abstractions should be placed in one package and the rest of the packages should depend upon this abstraction package.

Abstraction Metric

A simple metric can help determining the abstraction of a package. The formula for measuring abstractness is:

A = Na/Nc

Where

Na = number of abstract classes or interfaces in a package

Nc = number of concrete classes in a package

A = abstractness of a package

Clearly, A->0 means that the package contains less abstract classes than concrete classes in it, whereas, A->1 means the package contains more abstract classes than concrete classes in it.

A package becoming more abstract means it is becoming more stable. This means more and more packages will depend on this package and it will become more unstable (with stability factor nearing 0). One important thing in the abstraction metric is that it is better to have the abstractness (A) nearing 0 or 1. Then, the package tends to become either stable or unstable. A value of 0.5 indicates that the package is neither stable nor unstable and therefore difficult to manage.

Conclusion

This brings us to the end of discussion of designing packages in Object Oriented Programming. Adhering to these principles along with all the class design principles I have discussed in this series will help you to come up with a robust and unstable (that is what we want, don�t be mistaken) application design. In the next month, I will present an example with all these principles in practice. Until then goodbye.

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.