1

Principles of Package Design

Chien-Tsun ChenDepartment of Computer Science and Information EngineeringNational Taipei University of Technology, Taipei 106, Taiwan

ctchen@ctchen.idv.twMay 26 2005

OOD principles roadmap: What distinguish good and bad OO design?

Class

Inheritance

polymorphism

Program to an interface, not an implementation

Favor object composition over class inheritance

Separation of concern

Single Responsibility

Open-Closed

Liskov Substitution

Dependency-Inversion

Interface-Segregation

basic advanced

2

OOD principles and principles of package design

Single Responsibility

Open-Closed

Liskov Substitution

Dependency-Inversion

Interface-Segregation

class package

Reuse-Release Equivalence

Common-Reuse

Common-Closure

Acyclic-Dependencies

Stable-Dependencies

Stable-Abstractions

Granularity

Stability

References

3

Outline

Granularity: The principles of Package CohesionREP—The Reuse-Release Equivalence PrincipleCRP—Then Common-Reuse PrincipleCCP—The Common-Closure Principle

Stability: The Principles of Package CouplingADP—The Acyclic-Dependencies PrincipleSDP—The Stable-Dependencies PrincipleSAP—The Stable-Abstractions Principle

What is Reuse-Release Equivalence Principle (REP)?

Definition: the granule of reuse is the granule of release.

If a package contains software that should be reused, then it should not also contain software that is not designed for reuse. Either all of the classes in a package are reusable or non of them are.

4

What do you expect from the author of a class library that you are planning to reuse?

Good documentation,Working codeWell-specified interface, etc. AndYou want the author to maintain it for you.You want the author to notify you in advance of any changes he plans to make to the interface and functionality of the code, giving you the option to refuse to use any new versions.

This issue is primarily political and has a profound effect on the packaging structure of software

To provide the guarantees that reusers need, authors must organize their software into reusable packages and then track those packages with release numbers Reusability comes only after there is a tracking system in place that offers the guarantees of notification, safety and support atha the potential reusers will need

5

We must also consider who the reuse is

GUI library Financial library

GUI library

Financial library

What is Reuse-Release Equivalence Principle (REP)?

Definition: the granule of reuse is the granule of release.

Either all of the classes in a package are reusable or non of them are.

6

Outline

Granularity: The principles of Package CohesionREP—The Reuse-Release Equivalence PrincipleCRP—Then Common-Reuse PrincipleCCP—The Common-Closure Principle

Stability: The Principles of Package CouplingADP—The Acyclic-Dependencies PrincipleSDP—The Stable-Dependencies PrincipleSAP—The Stable-Abstractions Principle

What is Common-Reuse Principle (CRP)?

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

Classes that tend to be reused together belong in the same package.

7

Reusable classes collaborate with other classes that are part of the reusable abstraction

Software system

P1 P2

P3

P4

When one package uses another, a dependency is created between the packages

Software system

P1 P2

P3

P4

8

Even if the using package only uses one class within the used package, the dependency is not weaken at all

Every time the used package (P2) is released, the using package (P1) must be revalidated and rereleased

P1 P2

P3

P4

changed

When you depend on a package, you depend on every class in that package

The classes you put into a package are inseparable, that it is impossible to depend on some and not the others.Otherwise, you will be revalidating and redistributing more than is necessary, wasting significant effort.

9

CRP tells more about what classes shouldn’t be together than what classes should be together

Classes which are not tightly bound to each other with class relationships should not be in the same package

What is Common-Reuse Principle (CRP)?

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

Classes that tend to be reused together belong in the same package.Classes which are not tightly bound to each other with class relationships should not be in the same package

10

Outline

Granularity: The principles of Package CohesionREP—The Reuse-Release Equivalence PrincipleCRP—Then Common-Reuse PrincipleCCP—The Common-Closure Principle

Stability: The Principles of Package CouplingADP—The Acyclic-Dependencies PrincipleSDP—The Stable-Dependencies PrincipleSAP—The Stable-Abstractions Principle

What is Common-Closure Principle (CCP)?

Definition: the classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package and no other packages.

This is the Single-Responsibility Principle restated for packages.

11

The Common-Closure Principle focuses on maintainability

If the code in an application must change, you would rather that the changes occur all in on package, rather than being distributed through many packages.The CCP minimizes the workload related to releasing, revalidating, and redistributing the software.

The Common-Closure Principle is closely associated with the Open-Closed Principle

The OCP states that classes should be closed for modification.

100% closure is not attainableWe design systems such that they are closed to the most common kinds of changes that we have experienced.

The CCP amplifiers this by grouping together classes that are open to certain types of changes into the same packages

12

Stability: the Principles of Package Coupling

Outline

Granularity: The principles of Package CohesionREP—The Reuse-Release Equivalence PrincipleCRP—Then Common-Reuse PrincipleCCP—The Common-Closure Principle

Stability: The Principles of Package CouplingADP—The Acyclic-Dependencies PrincipleSDP—The Stable-Dependencies PrincipleSAP—The Stable-Abstractions Principle

13

What is Acyclic-Dependencies Principle (ADP)?

Definition: Allow no cycles in the package-dependency graph.

To avoid morning-after syndrome

Package structures are a directed acyclic graph (DAG)

1

2

2

1

1

2

3

4

14

A package diagram with a cycle

How to testing

Breaking the cycle

Apply the Dependency-Inversion Principle

Create a new package on which both MyDialogsand MyApplication depend

15

The package structure cannot be designed from the top-down

Perspective of the package dependency diagrams:

Package dependency diagrams have very little to do with describing the function of the applicationThey are a map to the buildability of the applicationDo not try to design the package dependency structure before we had designed any classesThe package dependency structure grows and evolves with the logical design of the system

Outline

Granularity: The principles of Package CohesionREP—The Reuse-Release Equivalence PrincipleCRP—Then Common-Reuse PrincipleCCP—The Common-Closure Principle

Stability: The Principles of Package CouplingADP—The Acyclic-Dependencies PrincipleSDP—The Stable-Dependencies PrincipleSAP—The Stable-Abstractions Principle

16

What is Stable-Dependencies Principle (SDP)?

Definition: Depend in the direction of stability.

Modules that are intended to be easy to change are not depended on by modules that are harder to change than they are

What is stability?

stable(difficult to change)

instable(easy to change)

17

A package with lots of incoming dependencies is very stable

X is a stable package because is it difficult to change(X is responsible to A, B, and C)

A B C

A package with lots of outgoing dependencies is very instable

Y is a instable package because is it easy to change(Y is irresponsible to I, J, and K)

I J K

18

Stability metrics

(Ca) Afferent Couplings: The number of classes outside this package that depend on classes within this package(Ce) Efferent Couplings: the number of classes inside this package that depend on classes outside this package(Instability I): I = Ce / (Ca + Ce)

I has the range [0,1]I = 0 indicates a maximally stable packageI = 1 indicates a maximally instable package

An example for calculating stability metrics of the package Pc:

Ca = 3Ce = 1I = Ce / (Ca + Ce) = 1 / (3 + 1) = 0.25

in-1

in-2

in-3

out-1

19

How to count dependencies?

In C++Dependencies are typically represented by #includeOrganizing your source code such that there is one class in each source file will simplify the counting

In JavaCounting import statements and qualified names

The meaning of Stable-Dependencies Principle from the view point of I metrics

I metric of a package should be larger than the I metrics of the packages that it depends on (i.e., I metrics should decrease in the direction of dependency)

I = 0

I = 0.25

I = 1 I = 1

20

Not all packages should be stable: if all the packages were maximally stable, the system would be unchangeable

How to balance stability with flexibility?

Violation of SDP The cause of the bad dependency

Fixing the stability violation using DIP or creating a new package

Applying Dependency-Inversion Principle

Stable Flexible

IUU C

Creating a new package, and moving the class that the stabledepend on into the new package

I = 0.25

I = 0

I = 1

I = 1I = 0

21

The relationship between Open-Closed Principle and the Stable-Dependencies Principle

Some software (high-level architecture and design decisions) in systems should not change very often

If the high-level design is placed into stable packages, it would be difficult to change

The OCP tells us:A module should be open for extension (flexible), but closed for modification (stable)What kinds of classes are flexible enough to be extended without requiring modification?

Abstract classes and interfaces

Programming to interface, not to implementation

Outline

Granularity: The principles of Package CohesionREP—The Reuse-Release Equivalence PrincipleCRP—Then Common-Reuse PrincipleCCP—The Common-Closure Principle

Stability: The Principles of Package CouplingADP—The Acyclic-Dependencies PrincipleSDP—The Stable-Dependencies PrincipleSAP—The Stable-Abstractions Principle

22

What is Stable-Abstractions Principle (SAP)?

Definition: A package should be as abstract as it is stable.

Stability implies abstractionA stable package should also be abstract so that its stability does not prevent it from being extendedAn instable package should be concrete since its instability allows the concrete code within it to be easily changed

Measuring abstraction

(Nc) : The number of classes in the package(Na) : The number of abstract classes in the package(Abstractness A): A = Na / Nc

A has the range [0,1]A = 0 implies that the package has no abstract classesA = 1 implies that the package contains nothing but abstract classes

23

Defining the relationship between stability (I) and abstractness (A)

I = 0, A = 1maximally stable and abstract

I = 1, A = 0maximally instable and concrete

The A-I graph

Zones of exclusion: areas where packages should not be

The A-I graph

I = 0, A = 0maximally stable and concrete

I = 1, A = Imaximally instable and abstract

24

The main sequence: a package that sits on the main sequence is not too abstract for its stability, nor is it too instable for its abstractness

The A-I graph

Distance from the main sequence: package should be on or close to the main sequence

(Distance D): D = |A + I - 1| / √2D ranges from [0, ~0.707]

(Normalized Distance D’): D’ = |A + I - 1|D’ ranges from [0, 1]D = 0 indicates that the package is directly on the main sequenceD = 1 indicates that the package is as far away as possible from the main sequence

25

Using the D metric: calculate the mean and variance of all the D metrics

standard deviation

concrete and stable

abstract and instable

Using the D’ metric: plot the D’ metric of each package over time

a control threshold at D’ = 0.1

some strange dependencies have been creeping into the package over the last two releases

26

Applying the following package design principles well will help you in designing large software system

Question?

Single Responsibility

Open-Closed

Liskov Substitution

Dependency-Inversion

Interface-Segregation

Reuse-Release Equivalence

Common-Reuse

Common-Closure

Acyclic-Dependencies

Stable-Dependencies

Stable-Abstractions

Granularity

Stability

27

Modular Continuity [OOSC]

Definition: a method satisfies Modular Continuity if, in the software architectures that it yields, a small change in a problem specification will trigger a change of just one module, or a small number of modules.

Continuity means that small changes should affect individual modules in the structure of the system, rather than the structure itself.

A small change in the argument will yield a proportionally small change in the result

argument(specification)

result(system)

28

Breaking the cycle with dependency inversion

<<interface>>

29

Breaking the cycle with a new package

30

Examples of packages that fall within the Zone of Pain (I = 0, A = 0. Maximally stable and concrete)

Database schemaNotoriously volatile, extremely concrete, and highly depended on

Utility librariesstring (concrete , nonvolatile)