1 / 11

Chapter 36

Chapter 36. Package Design “’Commandments’ sounds a little harsh. Why can’t we call them the Ten Guidelines?” -- Moses. The Problem.

caspar
Télécharger la présentation

Chapter 36

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 36 Package Design “’Commandments’ sounds a little harsh. Why can’t we call them the Ten Guidelines?” -- Moses CS6359 Fall 2012 John Cole

  2. The Problem • In design, we can easily put classes in any cohesive package. In actual coding, the physical design, changes in a package can ripple through your entire program. • This is worse in C++ than Java CS6359 Fall 2011 John Cole

  3. Objectives • Organize packages to reduce the impact of changes. • Know alternative UML package structure notation. CS6359 Fall 2011 John Cole

  4. Guideline 1 • Package functionally cohesive vertical and horizontal slices • Relational cohesion: RC=Number of Internal Relations / Number of Types • Where Number of Internal Relations includes attribute and parameter relations, inheritance, and interface implementations between types in the package • Types = Classes CS6359 Fall 2011 John Cole

  5. Guideline 1 (continued) • A low RC value suggests: • The package contains unrelated things and is not factored well. • The package contains unrelated things and the designer deliberately does not care. This is common with utility packages of disparate services (e.g., java.util), where high or low RC is not important. • It contains one or more subset clusters with high RC, but overall does not. CS6359 Fall 2011 John Cole

  6. Guideline 2 • Package a family of inheritance • That is, place a set of functionally related interfaces in a package separate from their implementation classes • See javax.ejb: http://docs.oracle.com/javaee/5/api/javax/ejb/package-summary.html CS6359 Fall 2011 John Cole

  7. Guideline 3 • Package by work and by clusters of unstable classes • Packages, not classes, are usually the basic unit of work and of release • Suppose 1) there is an existing large package P1 with thirty classes, and 2) there is a work trend that a particular subset of ten classes (C1 through C10) is regularly modified and re-released. • In this case, refactor P1 into P1-a and P1-b, where P1-b contains the ten frequently worked on classes. CS6359 Fall 2011 John Cole

  8. Guideline 4 • Most responsible (depended upon) must be the most stable • A class is stable if it: • Contains only or mostly interfaces and abstract classes • Has no dependencies on other packages • Was well-tested before release • Has a slow change schedule CS6359 Fall 2011 John Cole

  9. Guideline 5 • Factor out independent types • That is, if there are classes in the package that are not required to be used together, separate them • (This also reduces code bloat) CS6359 Fall 2011 John Cole

  10. Guideline 6 • Use Factories to reduce dependency on concrete packages • Example of factory for payment type rather than new CreditCardPayment() CS6359 Fall 2011 John Cole

  11. Guideline 7 • No cyclic dependencies in packages • Redefine the depended-on classes in one of the packages to implement new interfaces. • Define the new interfaces in a new package. • Redefine the dependent types to depend on the interfaces in the new package, rather than the original classes. CS6359 Fall 2011 John Cole

More Related