Design II

1
Design II
CS 121 Ordering Chaos
Mike Michael A. Erlinger

• Today
• Design Principlescan we define them

intro.12.ppt
2
Design

• Practices
• Principles
• Patterns

How do we go about design and what do we produce?
What are the characteristics of good design?
What are good solutions to common design problems?
LAST TIME
3
Practices Forms of Models

• Diagrams (UML)
• Text (hyperlinked)
• Prototypes
• Mathematical models
• Charts, graphs

LAST TIME
4
Design

• Practices
• Principles
• Patterns

How do we go about design and what do we produce?
What are the characteristics of good design?
What are good solutions to common design problems?
TODAY Principles of design Are there any? Do
they matter? Can we evaluate them?
5
Goals at the Highest Level

1. Make it easy to build
2. Make it easy to test
3. Make it easy to maintain
4. Make it easy to change

SIMPLE
INTUITIVE
FLEXIBLE
6
Mountains and molehills
Design principles help manage the complexity
that arises as project size grows.
Software development in the Small vs
Large Problem is Small grows to Large
without a plan
7
Design Principle DRY
SIMPLE, INTUITIVE, FLEXIBLE
Dont repeat yourself data/code should occur once
and only once Examples ??
8
Design Principle
INTUITIVE
Use real world objects
Domain model
Design model
Abstract Game
Real Game console
9
Design Principle SRP
SIMPLE, INTUITIVE, FLEXIBLE
Single Responsibility Principle (SRP) every
class/object should have a single responsibility
Foundation of Software Development Functions
with single purpose, Objects, etc.
Several related principles Encapsulation,
Abstraction, etc.
10
Design Principle EV
related to SRP
Encapsulate Variation every class should have
only one reason to change
FLEXIBLE
Change should not cause a domino effect!
11
EV example
Purpose Convert images
Image processor
bmp,
bmp,
What happens when Input type changes?
12
EV example
Image processor
Image Loader
bmp, Sometime Later jpg, gif,
bmp, Sometime Later jpg, gif,
13
Design Principle HCLC
related to SRP
A class is cohesive if its data and methods are
strongly connected
High cohesion Low coupling
Classes have low coupling if they are only
loosely connected
14
Cohesion Examples

• Functional cohesion (SRP)
• Coincidental cohesion
• Logical cohesion
• Temporal/sequential cohesion
• Communicational

?
15
Cohesion Examples
BEST

• Functional cohesion (SRP) grouped because they
  contribute to a single well-defined task
• Coincidental cohesion grouped together because
• Logical cohesion grouped because they fall into
  some logical category, i.e. I/O
• Temporal/sequential cohesion grouped because
  they are processed at the same time or in
  sequence i.e. error handling (create log,
  notifies user, etc.)
• Communicational grouped because they operate on
  same data, e.g., operate on same record

WORST
16
Coupling Examples

• Content coupling
• Common coupling
• Control coupling
• Data-structure coupling
• Message coupling

?
17
Coupling Examples

• Content coupling a module or class relies on the
  implementation of another i.e. accessing private
  data
• Common coupling modules or classes share global
  data
• Control coupling one module controls the logic
  of another (e.g. passing a what-to-do flag)
• Data-structure coupling modules share composite
  data structure
• Message coupling modules communicate through
  interface

WORST
BEST
18
Design principle
Law of Demeter
only talk to your friends
Principle of Least Knowledge
no no no myGame-gttheBoard-gtcells00.update()
19
Design principle
The fundamental notion is that a given object
should assume as little as possible about the
structure or properties of anything else
(including its subcomponents).
Law of Demeter
only talk to your friends
Each unit should have only limited knowledge
about other units only units "closely" related
to the current unit. Each unit should only talk
to its friends don't talk to strangers. Only
talk to your immediate friends.
no no no myGame-gttheBoard-gtcells00.update()
Should not know details of theBoard
20
Design Principle
Open-Closed principle classes should be open to
extension but closed to modification
architecture of your game
21
Design Principle
Open-Closed principle classes should be open to
extension but closed to modification idea was
that once completed, the implementation of a
class could only be modified to correct errors
new or changed features would require that a
different class be created
architecture of your game
22
Composition and Inheritance
shape
shape
is a
is a
sphere
ball
sphere
has a
is a
ball
Design heuristic Think like an object!
23
Design Principle
Favor composition over inheritance
A
A
B
has a
isa
inheritance
composition
B
BLACK box reuse
WHITE box reuse
24
Design principle
Favor composition over inheritance
A
A
B
has a
isa
inheritance
composition
B
Caveat sometime inheritance is the right thing
(i.e. gives us polymorphism)
25
Design Principle LSP
Liskov substitution principle (LSP)
B
void doSomething(B myThingOfTypeB)
isa
void doSomething(C myThingOfTypeC)
C
this should work as well
not just any banana
26
LSP violation
class Rectangle public void SetWidth(double w)
itsWidthw void SetHeight(double h)
itsHeightw double GetHeight() const return
itsHeight double GetWidth() const return
itsWidth private double itsWidth double
itsHeight
rectangle
isa
square
some time later
27
LSP violation
class Rectangle public void SetWidth(double w)
itsWidthw void SetHeight(double h)
itsHeighth double GetHeight() const return
itsHeight double GetWidth() const return
itsWidth private double itsWidth double
itsHeight
rectangle
isa
void SquareSetWidth(double w) RectangleSetWi
dth(w) RectangleSetHeight(w) void
SquareSetHeight(double h) RectangleSetHeight
(h) RectangleSetWidth(h)
square
PROBLEMS?
28
LSP

• Assume a Square class that derives from a
  Rectangle class, assuming getter and setter
  methods exist for both width and height. The
  Square class always assumes that the width is
  equal with the height. If a Square object is used
  in a context where a Rectangle is expected,
  unexpected behavior may occur because the
  dimensions of a Square cannot (or rather should
  not) be modified independently.
• This problem cannot be easily fixed if we
  can modify the setter methods in the Square class
  so that they preserve the Square invariant (i.e.,
  keep the dimensions equal), then these methods
  will weaken (violate) the postconditions for the
  Rectangle setters, which state that dimensions
  can be modified independently.

29
LSP violation
class Rectangle public void SetWidth(double w)
itsWidthw void SetHeight(double h)
itsHeightw double GetHeight() const return
itsHeight double GetWidth() const return
itsWidth private double itsWidth double
itsHeight
rectangle
isa
square
A square is not a rectangle!! Its external
behavior is different
30
Design Principle
INTUITIVE
SIMPLE
FLEXIBLE
31
Summary

• Dont repeat yourself (D.R.Y)
• Use real world objects
• Single responsibility principle
• Encapsulate variation
• High cohesion/low coupling
• Program to an interface, not an implementation
• Law of Demeter (talk only to your friends)
• Favor composition over inheritance
• Open-closed principle
• Liskov Substitution Principle

32
Source Raymond, "Art of Unix Programming",
Addison-Wesley, 2003

• Rule of Modularity Write simple parts connected
  by clean interfaces
• Rule of Clarity Clarity is better than
  cleverness.
• Rule of Composition Design programs to be
  connected to other programs.
• Rule of Separation Separate policy from
  mechanism separate interfaces from engines
• Rule of Simplicity Design for simplicity add
  complexity only where you must
• Rule of Parsimony Write a big program only when
  it is clear by demonstration that nothing else
  will do
• Rule of Transparency Design for visibility to
  make inspection and debugging easier
• Rule of Robustness Robustness is the child of
  transparency and simplicity
• Rule of Representation Fold knowledge into data
  so program logic can be stupid and robust
• Rule of Least Surprise In interface design,
  always do the least surprising thing
• Rule of Silence When a program has nothing
  surprising to say, it should say nothing
• Rule of Repair When you must fail, fail noisily
  and as soon as possible
• Rule of Economy Programmer time is expensive
  conserve it in preference to machine time
• Rule of Generation Avoid hand-hacking write
  programs to write programs when you can
• Rule of Optimization Prototype before polishing.
  Get it working before you optimize it
• Rule of Diversity Distrust all claims for one
  true way
• Rule of Extensibility Design for the future,
  because it will be here sooner than you think

33
Agile Design Philosophies

• Agile Designs are Emergent
• Unit tests form detailed design doc WHEN do
  test-driven development (TDD)
• Design models need to be just barely good enough
• Multiple models used
• Use each model in multiple ways
• Designers should code
• Prove it with code
• Feedback is your friend (team and/or outsiders)
• Iterate, iterate, iterate
• Do design every day
• Document complicated things
• Do not over documentuntil the end

34
Agile Design Philosophies

• Incorporate continuous User feedback
• Understand your stakeholdersusers, management,
• Design for the user experience
• Make the app predictable
• Bring objects to life through UI

35
UNDER-PROMISE and OVER-DELIVER
36
The End
37
Trade offs
Class B
Class A
Class C
low cohesion
high coupling