Chapter 36
This presentation is the property of its rightful owner.
Sponsored Links
1 / 11

Chapter 36 PowerPoint PPT Presentation


  • 63 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Chapter 36

Chapter 36

Package Design

“’Commandments’ sounds a little harsh. Why can’t we call them the Ten Guidelines?”

-- Moses

CS6359 Fall 2012 John Cole


The problem

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


Objectives

Objectives

  • Organize packages to reduce the impact of changes.

  • Know alternative UML package structure notation.

CS6359 Fall 2011 John Cole


Guideline 1

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


Guideline 1 continued

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


Guideline 2

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


Guideline 3

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


Guideline 4

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


Guideline 5

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


Guideline 6

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


Guideline 7

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


  • Login