Title: Principles of Object-Oriented Software Development
1Principles of Object-Oriented Software Development
2Idioms and Patterns
Introduction Polymorphism Idioms
in hush A catalogue of design patterns
Event-driven computation Summary Q/A
Literature
3Idioms and Patterns
- polymorphism -- inheritance and delegation
- idioms -- realizing concrete types
- patterns -- a catalogue of design patterns
- events -- the reactor pattern
Additional keywords and phrases generic types,
assertions, canonical classes, event-driven
computation
4Polymorphism
Subsections Inheritance and delegation in
Java Polymorphism in C Assertions in
C Canonical class idioms
5Inheritance and delegation in Java
public class envelope
envelope public envelope()
public void message()
System.out.println("hello ... ")
6Factory
Envelope/letter pattern
7 public class envelop
envelope letter impl
public envelope() impl new letter()
public void message()
impl.message() public class
letter
letter public letter()
public void message()
System.out.println("Message in a letter")
8public class factory
factory
public factory() letter letter()
return new letter() envelope envelope()
return new envelope() public class
envelope
envelope letter impl public
envelope() factory f new factory()
impl f.letter() // obtained from
factory public void message()
impl.message()
9 public class singleton extends letter
singleton static int
number 0 protected singleton()
static letter instance() if (number0)
theletter new letter()
number 1
return theletter public void
message() System.out.println("Message
in a letter") static letter
theletter
10Polymorphism in C
Overloading
print extern
void print(int) extern void print(float)
Generic class -- templates
listlt T gt templatelt class T
gt class list ... listltintgt alist
Polymorphism by inheritance
shape class shape ...
class circle public shape ...
shape s new circle
11Standard Template Library
- containters -- to hold objects
- algorithms -- act on containers
- iterators -- to traverse containers
- functions -- as objects
- adaptors -- to transform objects
- allocators -- for memory management
12Assertions in C
double sqrt( double arg )
sqrt require ( arg gt 0
) double rarg, x1, eps0.0001 while(
fabs(r - x) gt eps ) rx
xr-((rr-arg)/(2r)) promise ( r - arg
arg lt eps ) return r
13class counter
counter
public counter(int n 0) _n(n)
require( n gt 0 ) promise( invariant()
) check
initial state virtual void
operator() require( true )
empty
pre-condition hold()
save the
previous state _n 1 promise( _n
old_n 1 invariant() ) int
value() const return _n
no side effects virtual bool
invariant() return value() gt 0
protected int _n int old_n virtual void
hold() old_n n
14class bounded public counter
bounded public
bounded(int b MAXINT) counter(0), max(b)
void operator() require( value() lt
max ) to prevent
overflow counteroperator()
bool invariant() return value()
lt max counterinvariant()
private int max
15Canonical class idioms
16Canonical class in C
- default constructor
- copy constructor
- destructor
- assignment
- operators
Abstract data types must be indistinguishable
from built-in types
17Idioms in hush
Subsections The handle/body idiom
Virtual self-reference Dynamic role
switching The art of hush programming
18The hush framework
19Basic hush classes
- session -- to manage (parts of) the application
- kit -- to provide access to the underlying system
and interpreter - handler -- to bind C functionality to events
- event -- stores information concerning user
actions or system events - widget -- to display information on a screen
- item -- represents an element of a widget
20kit
interface kit
kit void eval(string
cmd) string result() void
bind(string name, handler h)
21handler
interface handler
handler int dispatch( event e
)
// to dispatch
events int operator()
22widget
interface widget handler
widget ... void
bind( handler h ) void bind( string
action, handler h ) ...
23event
interface event handler
event
operator()
24The Handle/Body Idiom
class A
A -- naive public A()
public void f1() System.out.println("A.f1
") f2() public void f2()
System.out.println("A.f2")
25 class A
A public A() body new
BodyOfA(this) protected A(int x)
public void f1() body.f1() public void
f2() body.f2() public void f3()
System.out.println("A.f3") private A
body
Interface A
26 class BodyOfA extends A
BodyOfA -- naive public
BodyOfA() super(911) public void f1()
System.out.println("A.f1") f2() public void
f2() System.out.println("A.f2")
class C extends A
C public void f2() System.out.println("C.f2
")
slide Usage C
C c new C c.f1()
// instantiate
27 class BodyOfA extends A
BodyOfA public
BodyOfA(A h) super(911) handle h
public void f1() System.out.println("A.f1")
handle.f2() public void f2()
System.out.println("A.f2") A handle
reference to
invocation context
28(No Transcript)
29Virtual self-reference
class item
item public
item(String x) _name x _self null
String name() return exists()?self().name()_na
me public void redirect(item x) _self
x boolean exists() return _self !
null public item self() return
exists()?_self.self()this item _self
String _name
30public class go public static void
main(String args) item a new
item("a") item b new item("b")
a.redirect(b) System.out.println(a.name(
)) indeed, b
31Dynamic role-switching
32class actor
actor
public static final int Person 0 public
static final int Student 1 public static
final int Employer 2 public static final int
Final 3 public void walk() if
(exists()) self().walk() public void talk()
if (exists()) self().talk() public void
think() if (exists()) self().think()
public void act() if (exists()) self().act()
public boolean exists() return false
public actor self() return this
public void become(actor A) public void
become(int R)
33class student extends actor
student public
void talk() System.out.println("OOP")
public void think() System.out.println("Z")
class employer extends actor
employer
public void talk() System.out.println("money")
public void act() System.out.println("busine
ss")
34class person extends actor
person
public person() role new actor
Final1 for( int i Person i lt
Final i ) roleithis
become(Person) public boolean
exists() return role_role ! this
public actor self() if ( role Person
! this ) return role Person .self()
else return role_role
...
35 public void become(actor p)
role Person p public void
become(int R) if (role Person ! this)
self().become(R) else _role R
if ( role_role this )
switch(_role) case Person
break // nothing
changes case Student
role_role new student() break
case Employer role_role new employer()
break case Final role_role
new actor() break default
break //
nothing happens int _role
actor role
36 class adult extends person
adult public void
talk() System.out.println("interesting")
37 public class go
example
public static void main(String args)
person p new person() p.talk()
empty
p.become(actor.Student) p.talk()
OOP
p.become(actor.Employer) p.talk()
money p.become(new
adult()) p.talk()
interesting p.become(actor.Student)
p.talk()
OOP p.become(p) p.talk()
old role employer
p.become(actor.Person) p.talk()
// initial state
38The art of hush programming
39Invocation Context
handle/body Problem
Inheritance breaks with handle/body
Background Envelope/Letter, hiding
implementations Realization Explicit
invocation contact in body Usage sessions,
events, kits, widgets, items
40Nested Components
virtual self-reference Problem
Realizing composites with single inheritance
Background Decorators, Prototypes
Realization Smart delegation Usage
Composite widgets, Embedded logic
41Actor Pattern
dynamic role switching Problem
Static type hiearchies may be too limited
Background State transitions,
self-reference Realization Dynamic
instantiation and delegation Usage Web
viewer, kit -- embedded logic
42A catalogue of design patterns
Subsections Creational Patterns
Structural Patterns Behavioral Patterns
43A Catalogue of Design Patterns
- a common design vocabulary
- documentation and learning aid
- an adjunct to existing methods
- a target for redesign
44 The Pattern Schema Name
- handle increases design
vocabulary Problem - when to apply explains
the problem and the conflict Solution - general
arrangement design, responsibilities,
collaborations Consequences - tradeoffs to
understand the costs and benefits
45Causes for Redesign
design for change
- creating an object by specifying a class
explicitly -- Abstract Factory, Factory Method,
Prototype - dependence on specific operations -- Chain of
Responsibilty, Command - dependence on hardware software platforms --
Abstract Factory, Bridge - dependence on object implementation or
representation --Abstract Factory, Bridge,
Memento, Proxy
46- algorithm dependence -- Iterator, Strategy,
Template Method, Visitor - extending functionality by subclassing --
Bridge, Composite, Decorator, Observer - tight coupling -- Abstract Factory, Bridge, Chain
of Responsibilities, Command, Facade, Mediator,
Observer - inability to alter classes conveniently --
Adaptor, Decorator,
47Creational Patterns
48Creational Patterns
- Factory -- hide concrete classes
- Factory Method -- virtual constructors
- Prototype -- dynamic creation by cloning
- Singleton -- one instance only
49Structural Patterns
object and class composition
Pattern Alias
Remarks Composite
part/whole
collections of components Flyweight
part/whole extrinsic
state, many objects
Adaptor
wrapper
resolves inconsistencies Bridge
handle/body abstraction to
implementation Decorator
wrapper to introduce
functionality Facade
wrapper provides unified
interface Proxy
surrogate to defer ... remote,
virtual,
protection
50Behavioral Patterns
cooperation algorithms and the assignment of
responsibilities between objects class
Template Method -- the skeleton of an algorithm
Interpreter -- to evaluate expressions
object
composition Mediator -- provides indirection
Chain of Responsibility -- connect objects
to interact Observer -- to handle
dependencies
51Encapsulating behavior
objectify!
- Command -- action undo
- Strategy -- choice of algorithms
- Visitor -- decouple traversal and operations
- Iterator -- access and traversal
- State -- object state -gt behavioral change
52The Observer Pattern
Observer one-to-many dependencies and
notification Consequences abstract coupling
between subject and observer constraint
propagation deals with unexpected updates
53(No Transcript)
54Event-driven computation
Subsections The Reactor Pattern
Abstract event systems
55The Reactor Pattern
- activate handlers when events occur
- allow events from multiple sources
- in single threaded process
See D.C. Schmidt, Using Design Patterns to
Develop Reusable Object-oriented
Communication Software, CACM October '95,
38(10) 65-74
56(No Transcript)
57(No Transcript)
58Abstract event systems
th new centigrade() th new
fahrenheit() th.set(f) f th.get()
For thermometer th, th1 float f
Abstract
system -- thermometers
59 class thermometer
thermometer
protected thermometer( float v ) temp v
public void set(float v) temp v
public float get() return temp
protected float temp
60 class centigrade extends thermometer
centigrade public
centigrade() super(0) public void
set(float v) temp v 273 public float
get() return temp - 273
class fahrenheit extends thermometer
fahrenheit public
fahrenheit() super(0) public void
set(float v) temp (v - 32) 5/9 273
public float get() return temp 9/5 32 -
273
61 class displayer extends window
displayer
public displayer() ... public void
put(String s) ... public void put(float f)
...
class prompter extends window
prompter public
prompter(String text) ... public float
get() ... public String gets() ...
62abstract class event
event
pubic void dependent(event e) ... pubic
void process() ... public void operator()
// abstract method private event dep
63 class update extends event
update
public update(thermometer th, prompter p)
_th th _p p void
operator()() _th.set( _p.get() )
process() thermometer _th
prompter _p
64 class show extends event
show
public show(thermometer th, displayer d)
_th th _d d public void
operator() _d.put( _th.get() )
process() thermometer _th
displayer _d
65 thermometer c new centigrade() thermometer
f new fahrenheit() displayer cd new
displayer("centigrade") displayer fd new
displayer("fahrenheit") prompter cp new
prompter("enter centigrade value") prompter fp
new prompter("enter fahrenheit value")
show sc new show(c,cd) show sf new
show(f,fd) update uc new update(c,cp)
update uf new update(f,fp)
Installing the objects
66 uc.dependent(sc) uc.dependent(sf)
uf.dependent(sc) uf.dependent(sf)
Assigning dependencies
67Summary
68Polymorphism
1
- inheritance and delegation in Java
- polymorphism in C
- assertions in C
- canonical class idioms
69Idioms in hush
2
- the handle/body idiom
- virtual self-reference
- dynamic role switching
- the art of hush programming
70A catalogue of design patterns
3
- creational patterns
- structural patterns
- behavioral patterns
71Event-driven computation
4
- the Reactor pattern
- abstract event systems
72Questions
1.How would you explain the letter/envelope
idiom? 2.Characterize the notion of
polymorphism. Give some examples. 3.What is a
canonical class? Characterize its ingredients and
give an example. 4.Give a brief description of
the handle/body idiom, virtual self-reference,
and dynamic role switching. 5.What kinds of
patterns can you distinguish? Why do you consider
patterns to be of relevance. 6.Give a detailed
description of the Factory pattern. And also of
the Observer pattern. 7.Describe the Reactor
pattern. Why is it useful? 8.Give an example of
a system based on event-driven computation.
73Further reading
For an introduction to Java, there is ample
choice. An excellent online tutorial can be found
on http//java.sun.com/docs/books/tutorial As
textbooks on C I recommend Lippman91, and for
the more advanced reader Stroustrup98. For an
extensive introduction to STL, read STL.
Coplien92 is the original introduction to
idioms in C. The by now classical book for
patterns is GOF94. Well worth reading are the
many articles in the POPL proceedings, POPL1,
POPL2, POPL3.