Principles of Package Design

Principles of Package Design Chien-Tsun Chen Department of Computer Science and Information Engineering National Taipei University of Technology, Taipei 106, Taiwan [email protected] May 26 2005

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

Separation of concern

Open-Closed

Inheritance

Program to an interface, not an implementation

Liskov Substitution

polymorphism

Favor object composition over class inheritance

Dependency-Inversion Interface-Segregation

basic

advanced

1

OOD principles and principles of package design Reuse-Release Equivalence

Single Responsibility Granularity Open-Closed

Common-Reuse Common-Closure

Liskov Substitution Acyclic-Dependencies Dependency-Inversion Interface-Segregation

class

Stability

Stable-Dependencies Stable-Abstractions

package

References

2

Outline

Granularity: The principles of Package Cohesion REP—The

Reuse-Release Equivalence Principle CRP—Then Common-Reuse Principle CCP—The Common-Closure Principle

Stability: The Principles of Package Coupling ADP—The

Acyclic-Dependencies Principle SDP—The Stable-Dependencies Principle SAP—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.

3

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

Good documentation, Working code Well-specified interface, etc. And You 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

4

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.

5

Outline





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.

6

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

P3

P1

P2

P4

Software system

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

P3

P1

P2

P4

Software system

7

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

P3

P1

P2

P4

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

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.

8

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

9

Outline





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.

10

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 attainable We 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

11

Stability: the Principles of Package Coupling

Outline





12

What is Acyclic-Dependencies Principle (ADP)?

Definition: Allow no cycles in the packagedependency graph.

To avoid morning-after syndrome

Package structures are a directed acyclic graph (DAG) 4

3 2

2 1 1

1

2

13

A package diagram with a cycle

How to testing

Breaking the cycle

Apply the Dependency-Inversion Principle

Create a new package on which both MyDialogs and MyApplication depend

14

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 application They are a map to the buildability of the application Do not try to design the package dependency structure before we had designed any classes The package dependency structure grows and evolves with the logical design of the system

Outline





15

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?

instable (easy to change)

stable (difficult to change)

16

A package with lots of incoming dependencies is very stable

A

B

C

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

A package with lots of outgoing dependencies is very instable

I

J

K

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

17

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 package I = 1 indicates a maximally instable package

An example for calculating stability metrics of the package Pc:

in-2 in-3

out-1 in-1

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

18

How to count dependencies?

In C++ Dependencies

are typically represented by #include Organizing your source code such that there is one class in each source file will simplify the counting

In Java Counting

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=1

I=1

I=0 I = 0.25

19

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

Violation of SDP

The cause of the bad dependency

How to balance stability with flexibility?

Fixing the stability violation using DIP or creating a new package Stable

U

I=0

I=1

Flexible

C

IU

Applying DependencyInversion Principle

I = 0.25 I=1 I=0

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

20

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





21

What is Stable-Abstractions Principle (SAP)?

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

Stability implies abstraction A

stable package should also be abstract so that its stability does not prevent it from being extended An 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 classes A = 1 implies that the package contains nothing but abstract classes

22

Defining the relationship between stability (I) and abstractness (A) I = 0, A = 1 maximally stable and abstract

I = 1, A = 0 maximally instable and concrete

The A-I graph

Zones of exclusion: areas where packages should not be

I = 1, A = I maximally instable and abstract

I = 0, A = 0 maximally stable and concrete

The A-I graph

23

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| / √2 D

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 sequence D = 1 indicates that the package is as far away as possible from the main sequence

24

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

concrete and stable

standard deviation

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

25

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

Reuse-Release Equivalence Granularity

Open-Closed

Common-Reuse Common-Closure

Liskov Substitution Acyclic-Dependencies Dependency-Inversion

Stability

Stable-Dependencies Stable-Abstractions

Interface-Segregation

Question?

26

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)

27

Breaking the cycle with dependency inversion

28

Breaking the cycle with a new package

29

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

Database schema Notoriously

volatile, extremely concrete, and highly depended on

Utility libraries string

(concrete , nonvolatile)

30