1 / 37

Principles of Package Design

Packages: Tools for High-level Organization. Classes are too fine-grained to organize large applicationsSix principles for using packagesThree for package cohesion

dillon
Télécharger la présentation

Principles of Package Design

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 20 Principles of Package Design

    2. Packages: Tools for High-level Organization Classes are too fine-grained to organize large applications Six principles for using packages Three for package cohesion – help us decide how to allocate classes to packages Three for package coupling – determine how packages should be interrelated. Include Dependency Management (DM) metrics to measure and characterize designs.

    3. Designing with packages What are the principles for allocating classes to package? What design principles govern the relationships between packages? Should packages be designed before classes (top down) or should classes be designed before packages (bottom up)? How are packages physically represented? In C++? In Java? In development environment? Once created, to what purpose will we put these packages?

    4. Reuse-Release Equivalence Principle (REP) The granule of reuse is the granule of release. Anything we reuse must be released and tracked. We want author to: maintain code (otherwise too much effort for us!) notify us if plans to change it, give option to refuse new version Consider the internal contents of package from point of view of potential reusers. Either all of the classes in a package are reusable or none of them are. Should also consider who reuser is. Container is reusable. Financial framework is reusable. Should not be in same package.

    5. Common-Reuse Principle (CRP) The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all. Classes generally collaborate; these belong in same package. Example: container + iterators. Important point: what classes not to put in package. If class only uses one class within package, still a dependency, still must be re-tested every time package is modified and released. Often put package into jar. If put too much in jar, then every time anything changes, jar must be redistributed, all dependent classes re-tested. Waste of time. CRP = tightly bound

    6. Common-Closure Principle (CCP) The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all classes in that package and no other packages. Single-Responsibility Principle for packages. Maintainability is often more important than reusability. If change occurs, would prefer it is all within one package. If two classes are so tightly bound they always change together, they belong in the same package.

    7. Acyclic-Dependencies Principle (ADP) Allow no cycles in the package-dependency graph. “Morning-after syndrome” – work all day, get some stuff working, go home, arrive next morning to find your stuff no longer works. Why? Someone else stayed later than you and changed something you depend on. ? Releasable packages. Checked out by developer. Update, test, give new release number, move back for others to use. Teams can choose when to move to new release. No team is at the mercy of others. Integration happens in small increments. But there can be no cycles.

    8. Package Structure as Directed (Acyclic) Graph

More Related