Principles of Object-Oriented Design

Lecture 6 1

Object-Oriented Reengineering

Radu Marinescu

Principles of Object-Oriented Design

Part II

Lecture 6 2


Radu Marinescu

The Law of Demeter

Any object receiving a message in a given method must be one of a restricted set of objects.

1. Strict Form: Every supplier class or object to a method must be a preferred supplier

2. Minimization Form: Minimize the number of acquaintance classes / objects of each method

Lieberherr and Holland

Lecture 6 3


Radu Marinescu

Shy Code§ Don't reveal yourself to others§ Don't interact with to many people

§ Spy, dissidents and revolutionaries4eliminating interactions protects anyone

§ The General contractor example4he must manage subcontractors

Lecture 6 4


Radu Marinescu

Law of Demeter

§ Minimize the number of acquaintances which directly communicate with a supplier4easier to contain level of difficulty per method4 reduces amount of rework needed if supplier’s interface is

modified4So only allow “certified” classes to call supplier

CertifiedAcquaintances

Preferred Supplier

Lecture 6 5


Radu Marinescu

Demeter’s “Good Style”

§ Access supplier methods only through methods of “preferred acquaintances”4bypass preferred supplier only if later optimization demands

direct access

X

Good style dictates that red client only access blue supplier via a method in a certified acquaintance

Red client violates LoD if it performs any direct calls to the blue supplier, no matter how it got the reference

AcquaintanceSupplierClient

Lecture 6 6


Radu Marinescu

directly held component objectscreated objects

passed parametersitself

Demeter’s Law for Functionsclass Demeter {private:A *a;

public:// …void example(B& b);

void Demeter::example(B& b) {C c;int f = func();b.invert();a = new A();a->setActive();c.print();

}

Any methods of an object should call only methods belonging to:

Lecture 6 7


Radu Marinescu

Acceptable LoD Violations

§ If optimization requires violation4Speed or memory restrictions

§ If module accessed is a fully stabilized “Black Box”4No changes to interface can reasonably be expected due to

extensive testing, usage, etc.

§ Otherwise, do not violate this law!!4Long-term costs will be very prohibitive

Lecture 6 8


Radu Marinescu

Interface Segregation Principle

§ Many client-specific interfaces are better than one general purpose interface

§ Consequence: 4 impact of changes to one interface aren’t as big if interface is

smaller4 interface pollution

Clients should not be forced to depend upon interfaces that they do not use.

R. Martin, 1996

Lecture 6 9


Radu Marinescu

Interface Segregation Principle (2)

Lecture 6 10


Radu Marinescu

ISP Example § Door and Timed Door

§ Timer Client

Lecture 6 11


Radu Marinescu

High-Level Design

§ Dealing with large-scale systems4> 50 KLOC 4 team of developers, rather than an individual

§ Classes are a valuable but not sufficient mechanism 4 too fine-grained for organizing a large scale design4need mechanism that impose a higher level of order

u clusters (Meyer); class-category (Booch); subject-areas (Coad)

Packages4a logical grouping of declarations that can be imported in other

programs (in Java and Ada) 4containers for a group of classes (UML)

u reason at a higher-level of abstraction

Lecture 6 12


Radu Marinescu

Issues of High-Level DesignGoal

4partition the classes in an application according to some criteria and then allocate those partitions to packages

Issues4What are the best partitioning criteria?4What principles govern the design of packages?

u creation and dependencies between packages

4Design packages first? Or classes first?u i.e. top-down vs. bottom-up approach

Approach4Define principles that govern package design

u the creation and interrelationship and use of packages

Lecture 6 13


Radu Marinescu

Principles of OO High-Level Design

§ Cohesion Principles 4Reuse/Release Equivalency Principle (REP)4Common Reuse Principle (CRP)4Common Closure Principle (CCP)

§ Coupling Principles 4Acyclic Dependencies Principle (ADP)4Stable Dependencies Principle (SDP)4Stable Abstractions Principle (SAP)

Lecture 6 14


Radu Marinescu

What is really Reusability ?

§ Does copy-paste mean reusability?4Disadvantage: You own that copy!

u you must change it, fix bugs.u eventually the code diverges

4Maintenance is a nightmare

§ Martin’s Definition: 4 I reuse code if, and only if, I never need to look at the source-code4 treat reused code like a product ⇒ don’t have to maintain it

§ Clients (re-users) may decide on an appropriate time to use a newer version of a component release

Lecture 6 15


Radu Marinescu

Reuse/Release Equivalency Principle (REP)

§ What means this ? 4A reusable software element cannot really be reused in practice

unless it is managed by a release system of some kindu e.g. release numbers or names

4All related classes must be released together4Release granule ≥ Reuse granule

u no reuse without release u must integrate the entire module (can’t reuse less)

4Classes are to small u we need larger scale entities, i.e. package

The granule of reuse is the granule of release.Only components that are released through a

tracking system can be efficiently reused.R. Martin, 1996

Lecture 6 16


Radu Marinescu

The Common Reuse Principle

All classes in a package [library] should be reused together. If you reuse one of the classes in the package,

you reuse them all.R. Martin, Granularity 1996

u Packages of reusable components should be grouped by expected usage, Not:u common functionality, noru another arbitrary categorization.

u Classes are usually reused in groups based on collaborations between library classes

Lecture 6 17


Radu Marinescu

Common Reuse in Practice

u The Façade Pattern becomes critical when the level of reuse becomes a targeted goal:

u If you started with…

(e.g. a mess!)

Lecture 6 18


Radu Marinescu

The Façade Solution

“Façade” says you should clean it up like this:

Lecture 6 19


Radu Marinescu

Common Closure Principle (CCP)

§ What means this ? 4Classes that change together belong together4Goal: limit the dispersion of changes among released packages

u changes must affect the smallest number of released packages

4Classes within a package must be cohesive4Given a particular kind of change, either all classes or no class

in a component needs to be modified

The classes in a package should be closed against the same kinds of changes.

A change that affects a package affects all the classes in that package

R. Martin, 1996

Lecture 6 20


Radu Marinescu

Reuse vs. Maintenance

§ REP and CRP makes life easier for reuser4packages very small

§ CCP makes life easier for maintainer4 large packages

§ Packages are not fixed in stone4early lifetime dominated by CCP4 later you want to reuse: focus on REP CRP

Lecture 6 21


Radu Marinescu

Acyclic Graph of Dependencies

Lecture 6 22


Radu Marinescu

Cyclic Dependencies

Lecture 6 23


Radu Marinescu

Acyclic Dependencies Principles (ADP)

The dependency structure for released component must be a Directed Acyclic Graph (DAG)

There can be no cycles.R. Martin, 1996

Lecture 6 24


Radu Marinescu

Breaking the Cycles

Lecture 6 25


Radu Marinescu

“Copy” Program Revisited

Copy

Reader Writer

KeyboardReader

PrinterWriter

DiskWriter

class Reader {public:

virtual int read()=0;};

class Writer {public:

virtual void write(int)=0;};

void Copy(Reader& r, Writer& w){int c;while((c = r.read()) != EOF)

w.write(c);}

Lecture 6 26


Radu Marinescu

Good Dependencies

§ Lack of interdependencies4 makes the “Copy” program robust, maintainable, reusable

§ Targets of unavoidable dependencies are non-volatile4unlikely to change4e.g. Reader and Writer classes have a low volatility ⇒

the Copy class is “immune” to changes

A “Good Dependency” is a dependency upon something with low volatility.

Lecture 6 27


Radu Marinescu

Volatility and Stability§ Volatility Factors

4hard-coding of improper informationu e.g. print version number

4market pressure4whims of customers

§ Volatility is difficult to understand and predict

§ Stability4defined as “not easily moved”4a measure of the difficulty in changing a module

u not a measure of the likelihood of a change

4Stabile = Independent + Responsible4modules that are stable are going to be less volatile

u e.g. Reader and Writer classes are stable

Lecture 6 28


Radu Marinescu

Stability Metrics

§ Afferent Coupling (Ca)4number of classes outside the package that depend upon the

measured packageu "how responsible am I?" (FAN-IN)

§ Efferent Coupling (Ce)4number of classes outside the package that classes within the

measured package depend onu "how dependent am I ?" (FAN-OUT)

§ Instability Factor (I)4 I ∈ [0, 1]4 0 = totally stable; 1 = totally unstable

ea

e

CCC

I+

=

Lecture 6 29


Radu Marinescu

Computing Stability Metrics

Lecture 6 30


Radu Marinescu

Stable Dependencies Principle (SDP)

The dependencies between components in a design should be in the direction of stability.

A component should only depend upon components that are more stable than it is.

R. Martin, 1996

Depend only upon components whose I metric is lower than yoursR. Martin, 1996

SDP Violation

Lecture 6 31


Radu Marinescu

Where to Put High-Level Design?§ High-level architecture and design decisions don't change often

4shouldn't be volatile ⇒ place them in stable packages4design becomes hard to change ⇒ inflexible design

§ How can a totally stable package (I = 0) be flexible enough to withstand change? 4 improve it without modifying it...

§ Answer: The Open-Closed Principle4classes that can be extended without modifying them

⇒ Abstract Classes

Lecture 6 32


Radu Marinescu

Stable Abstractions Principle (SAP)

§ Ideal Architecture4 Instable (changeable) packages on the top

u must be concrete

4Stable (hard to change) package on the bottom u hard to change, but easy to extendu highly abstract (easily extended)u Interfaces have more intrinsic stability than executable code

§ SAP is a restatement of DIP

The abstraction of a package should be proportional to its stability!Packages that are maximally stable should be maximally abstract.

Instable packages should be concrete.R. Martin, 1996

Lecture 6 33


Radu Marinescu

Measuring Abstraction § Abstraction of a Package

4A ∈ [0, 1]40 = no abstract classes41 = all classes abstract

NoClassesClasseNoAbstract

A =

§ Metric A is imperfect, but usable

4hybrid classes are also counted as abstract

uincluding pure virtual functions

§ Alternative

4find a metric based on the ratio of virtual functions

Lecture 6 34


Radu Marinescu

The Main Sequence

Instability (I) should increase as abstraction (A) decreases.R. Martin, 2000

Lecture 6 35


Radu Marinescu

Main Sequence (contd.)

§ Zone of Pain4highly stable and concrete ⇒ rigid4 famous examples:

u database-schemas (volatile and highly depended-upon)u concrete utility libraries (instable but non-volatile)

§ Zone of Uselessness4 instable and abstract ⇒ useless

u no one depends on those classes

§ Main Sequence4maximizes the distance between the zones we want to avoid4depicts the balance between abstractness and stability.

Lecture 6 36


Radu Marinescu

Measurement of OO Architectures § Distance

§ Normalized Distance

2|1| −+

=IA

D 4ranges from [0, ~0.707]

|1| −+= IAD 4ranges from [0, 1]4 0 = package on the main sequence4 1 = package far away from main seq.

Date post:	18-Dec-2021
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Principles of Object-Oriented Design

Documents