Post on 22-Aug-2020
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)