Transcript Lecture 10 • Generic programming (STL etc.) • Environmental acquisition

Lecture 10
• Generic programming (STL etc.)
• Environmental acquisition
• Better separation of concerns in AP
– Rondo influence
– modification relationship for visitors
– component-connectors approach for visitors
• Review lectures 1-9
5/23/2016
AOO
1
Generic Programming
Has similar goals as AP. Generic programming is about
parameterization and so is AP. The question is: what are
the parameters and how do you refer to them? Are the
parameters black boxes or white boxes?
5/23/2016
AOO
2
Connections to other disciplines
• Generic Programming
– a sub-discipline of computer science that deals
with finding abstract representations of efficient
algorithms, data structures and other software
concepts.
(Jazayeri, Loos, Musser, Stepanov: Motivation
for 1998 Schloss Dagstuhl seminar on Generic
Programming)
5/23/2016
AOO
3
Generic Programming
• Goal of generic programming: express
algorithms and data structures in a broadly
adaptable, interoperable form. Key ideas:
– express algorithms with minimal assumptions
about data abstractions, and vice versa.
– Lifting concrete algorithms to as general a level
as possible without losing efficiency.
5/23/2016
AOO
4
Environmental Acquisition
• Joseph Gil/David Lorenz (OOPSLA ‘96)
pages 214-231
• Nature versus Nurture: environmental
heredity controversy
– relative importance of heredity and
environment
– object behavior is determined at birth
(instantiation) and not the household
(composite object) of which it is part
5/23/2016
AOO
5
Acquisition in problem space
Door
color
from c:Car
to Door
before Door
print c.color
Sedan
from c:Hatchback
to Door
before Door
print c.color
Car
2..4
Color
propagation
of features
across links
Hatchback
5/23/2016
AOO
6
Environmental affect on a1
Classes
C3
Objects
C3 shared
features
a3
a2
C2
C1
5/23/2016
C2 shared
features
a1
C1 particular
features
C2 particular features
C1 shared
features
C3 particular features
AOO
7
Application domains
• There are abundant cases of containment
hierarchies where contained objects have
different behaviors depending on their
surrounding environment.
5/23/2016
AOO
8
Environmental Acquisition
• methods
ClassDef{// Concrete acquires print
void pc() to Concrete
{ (@ ClassDef c; @)
before ClassDef (@ c=host;@)
before Concrete
(@ c.print(); @)}
5/23/2016
AOO
9
Example: UML class diagram
ClassGraph
0..*
Entry
entries
EParse
ClassGraph
ClassDef
BParse
Body
parts
Part
className
0..*
super
ClassName
Concrete
5/23/2016
Note: we
use a
thick
arrow to
denote
inheritance.
UML uses an
open arrow.
Abstract
AOO
10
Example: UML class diagram
ClassGraph
0..*
Entry
entries
EParse
ClassGraph
ClassDef
BParse
Body
parts
Part
className
0..*
super
ClassName
Concrete
5/23/2016
Note: we
use a
thick
arrow to
denote
inheritance.
UML uses an
open arrow.
Abstract
AOO
11
Paths of Acquisition
• Aggregation links, containment
– composite with components
• Nonaggregation links
5/23/2016
AOO
12
Properties of aggregation
• An object may be a component of at most
one composite at any one time.
Document { // Unique acquisition
void print() to Character {
(@ int acqSize = 20 /* default */; @)
before Chapter (@ acqSize=… ; @)
before Section (@ acqSize=… ; @)
before Character
(@ /* print with acqSize */ @)
5/23/2016
AOO
13
Properties of Aggregation
• No object may be contained, directly or
indirectly, in itself. No circular acquisition.
Traversal will terminate.
• The protocol of a composite does not
depend on knowledge of its components.
• The protocol of a component does not
depend on knowledge of its composite.
5/23/2016
AOO
14
Environmental polymorphism
• Uncertainty that stems from the multitude
of potential object configurations. Two
sources:
– Containment freedom
• Same component may belong to composites of
different classes or occur stand alone.
– Subtype polymorphism
• traversal of class graph: all subclasses and
superclasses must be examined
5/23/2016
AOO
15
Subtype polymorphism
• Two ways in which subtype polymorphism
may affect composition
– Component Polymorphism
• If a superclass A of B may be contained in a
composite, then so may be B itself.
– Composite Polymorphism
• If a class Os may serve as a composite of a
component class En, then all classes inheriting from
Os are potential composites of En. Uncertainty with
respect to the class of the composite.
5/23/2016
AOO
16
Adaptive programming solutions
• Containment freedom
– start traversal at different source
• from Car to Door
• from Airplane to Door
• Subtype polymorphism
– follow inheritance edges backward
– follow inheritance edges forward if
construction edge follows
5/23/2016
AOO
17
Kinships between classes
• May kinship
– a class C1 may be contained in a class C2
• There is at least one path from C2 to C1
• Must kinship
– a class C1 must be contained in a class C2
• AP provides a containment path concept to
deal with kinships along which acquisition
takes place.
5/23/2016
AOO
18
Acquisition of features
• Acquisition of methods
– transport objects, check for non-null in case of
may kinship
• Acquisition of associations
– transport parts, check for non-null
5/23/2016
AOO
19
Conclusion
• Environmental acquisition is a useful
abstraction.
• Strategies can conveniently express the
scope of environmental acquisition.
Strategies even support what is called leap
acquisition.
• OOPSLA paper proposes OO language
extensions.
5/23/2016
AOO
20
Context Switch
• Better separation of concerns in AP
5/23/2016
AOO
21
Components of AP
• class graphs (C)
• strategies (S)
• structure-shy functionality (F)
• Main issue: how do we specify and
compose C, S and F, to maximize reuse of
any of them when the others change.
5/23/2016
AOO
22
Components of AP
C
Should not refer
to each other directly
5/23/2016
S
F
AOO
Each component should
hard-code as few
assumptions as possible
on the concrete form
of the others.
23
Components of AP
C
mixed connections
S->C
C->F
5/23/2016
S
C<->C
F<->F
F
AOO
24
Composition of visitors,
strategies and class graphs
Generic visitors
Strategy types
gv1
gv2
st1
st1
s1 = instantiation of
st1 for CG1
gv2(gv1)(s1 CG1)
s1
st1
Class graphs
gv1
CG1
s1
CG2
gv2
5/23/2016
instantiated
behavior
AOO
25
Component coupling in
Demeter/Java
• C-F coupling
– class dictionaries contain visitor classes
– visitor classes refer to class dictionaries
• Problem:
– change of cd necessary for change in visitor
– visitors not reusable
5/23/2016
AOO
26
Decoupling of C and F
• use generic visitors: parameterized by
strategy objects, use generic name change.
• change: abstractly denotes all traversing
methods over different class graphs. How
the visitor participates is expressed in code
associated with change.
5/23/2016
AOO
27
Component coupling in
Demeter/Java
• C-S coupling
– strategies refer to “task-important” classes also
used in class dictionaries
– strategies are expressed in terms of
implementation class dictionaries! That is a
problem
5/23/2016
AOO
28
Improvements for the C-S
coupling
• Use strategy types. In an instantiated
program we have strategies as objects.
• Strategies are instantiated from strategy
types.
5/23/2016
AOO
29
Component coupling in
Demeter/Java
• F-F coupling
– visitor classes refer to methods defined in other
visitor classes
– visitor classes refer to methods such as getcapacity.
• Problem
– visitor classes directly refer to each other (less
reusability)
5/23/2016
AOO
30
Improvements for F-F coupling
• parameterizing generic visitors with method
valued variables
– counting, summing, collecting etc.
• equip generic visitors with input and return
ports.
5/23/2016
AOO
31
Structure of a generic visitor
genericModVisitor(Strategy s, Method m1,…,mk){
//variables global for traversal
init()…
return()…
start()…
final()…
s.source
//variables that temp. extend host object
init()…
change()
host.m1();… next.return;… next();
host.localMethod1();…
localMethod1()(@ … @);…
}// end of visitor
5/23/2016
AOO
32
next
• next.return
– return method in next visitor is invoked
– next visitor is bound by modifies statement
• next()
– invokes the next implementation for the method
denoted by change (either next visiting task
attached to traversal denoted by change or the
remainder of the traversal)
5/23/2016
AOO
33
Composition of visitors,
strategies and class graphs
Generic visitors
Strategy types
gv1
gv2
st1
st1
s1 = instantiation of
ST1 for CG1
gv2(gv1)(s1 CG1)
s1
st1
Class graphs
gv1
CG1
s1
CG2
gv2
5/23/2016
instantiated
behavior
AOO
34
Component coupling in
Demeter/Java
• Coupling between components is pretty low
(thanks to strategies) but can be improved
further.
• Tension between
– convenience for programmer
• having to define many name mappings can be
perceived as inconvenient
– reduced coupling between components
5/23/2016
AOO
35
Improvements
• Parameterize adaptive programs (S,F
compositions) with class graphs.
– Refer to class-valued and relation-valued
variables when programs are written.
– When programs are used with a class graph,
specify mapping of variables to specific class
graph elements.
5/23/2016
AOO
36
C1
Components of AP
C2
S
C
interface
Should not refer
to each other directly
5/23/2016
F
AOO
Each component should
hard-code as few
assumptions as possible
on the concrete form
of the others.
37
Improvements
• Parameterize visitor classes with strategies
to reduce S-F coupling.
– Refer to class-valued and relation-valued
variables when visitors are written. Also refer
to parts of strategy s: s.source, s.target (classvalued variables parameterized by strategy).
– Define strategy kinds and write visitors in terms
of those.
5/23/2016
AOO
38
Improvements
• Strategy kind
– from Begin via Middle to End
• Strategy
– from A via B via C to D
• Mapping
– from Begin
via
– from A via B via
5/23/2016
AOO
Middle to End
C
to D
39
C1
Components of AP
C2
S1
C
interface
Should not refer
to each other directly
S
interface
F
S2
5/23/2016
AOO
40
Reduce coupling between visitors
• Visitor has a signature:
– provided
– required
5/23/2016
AOO
41
Visitor classes as components
return
visitor class
strategy
s
class graph
InitialVisitor
SummingVisitor
return
return
total
diff
sum what?
get_value
5/23/2016
CheckingVisitor
check what?
get_capacity
AOO
42
Container capacity problem
• need to sum: use SummingVisitor
• need to check: use CheckingVisitor
• want to do it in one traversal: need to store
sum when container is entered: InitialVisitor
5/23/2016
AOO
43
Earlier approach
• In an earlier solution, we nested the three
visitor classes; now we use another dynamic
relationship between them: modification
relationship.
5/23/2016
AOO
44
Interface of a visitor
• strategy (strategy type)
• class-valued variables
• relation-valued variables
– method-valued variables
• base objects
• information from and to other visitors
• visitors it modifies
5/23/2016
AOO
45
Container capacity problem
• CheckingVisitor
– data member: violations
– after each container, check whether difference
of sum at the end and the beginning
(InitialVisitor) of a container is larger than
capacity
– uses InitialVisitor (difference)
5/23/2016
AOO
46
Container capacity problem
• InitialVisitor
– store sum at beginning (SummingVisitor) of
container
– return difference beginning-end upon request
– uses SummingVisitor
5/23/2016
AOO
47
Reduced coupling
Warning: new syntax,
not implemented
• Container {
s1 = to Weight;
int check() by
Checking(s1, get_capacity)
modifies
Initial(s1)
modifies
Summing(s1, value)}
5/23/2016
AOO
48
Where to define visitor classes?
• not in class graph
• in separate visitor files *.vis or “inlined” in
*.beh files.
• generic.vis (PrintVisitor, CopyVisitor, …)
• visitor library for each application domain
– statistics (Sum, Count, Average, …)
– graph algorithms (Dft, CycleCheck, …)
5/23/2016
AOO
49
What is left in behavior files?
•
•
•
•
instantiate strategy types
instantiate parameterized visitor classes
define strategies
define adaptive methods of the
strategy/visitor style
5/23/2016
AOO
50
What is added to class graphs?
• define name map for class graph: defines
how class-valued variables and relationsvalued variables are mapped into a specific
class graph
5/23/2016
AOO
51
Reduced coupling, alternative
syntax Warning: new syntax,
not implemented
• Container {
s1 = to Weight;
int check() do s1 by
Checking(*, get_capacity)
modifies
Initial(*)
modifies
Summing(*, value)}
5/23/2016
AOO
52
Reduced coupling
Warning: new syntax,
not implemented
• Company {
s1 = to Salary;
float averageSal() do s1 by
Average //2 next visitors
modifies
Summing f=value,
Counting}
5/23/2016
AOO
53
Average Visitor
Average (Strategy s1) {
s1.source change /* old around */
(@ next();
int s = Summing.return();
int c = Counting.return(); @)
return (@ s/c @)
}
return
Summing
5/23/2016
AOO
Average
54
Modifies relationship examples
C
Average
I
S
Count
CycleCheck
UncondDft
Sum
5/23/2016
AOO
55
What can be in a visitor class
•
•
•
•
•
init
return: after traversal
change: like around
define parts in host and in visitor
start, final
5/23/2016
AOO
56
SummingVisitor
SummingVisitor (Strategy s,
Method f) {
int total_sum;
init (@ total_sum = 0; @)
return (@ total_sum @)
Warning: new syntax,
s.target
not implemented
change
(@ total_sum += host.f();
next(); @)}
5/23/2016
AOO
57
InitialVisitor
InitialVisitor (Strategy s) {
s.source /* old around */
int initial;
change
(@ initial = next.return();
next(); @)
return (@ next.return()
-initial @)
}
5/23/2016
AOO
58
CheckingVisitor
CheckingVisitor (Strategy s,
Method f) {
int violations;
init (@ violations = 0; @)
s.source(s) change
(@ next();
if (next.return() >
host.f())
…@)
return (@ violations @)}
5/23/2016
AOO
59
Summary
• Coupling between components C, S, and F
can be reduced by introducing ports on
components and by connecting them.
return
d
return
d
return connector
5/23/2016
AOO
60
Connection to software
architecture
• Components with input/output ports
• Connectors between ports
A{void f(){b.f1();}}
A{void f(){b.g1();}}
// in: B.f1() out: A.f() // connect A.g1 B.f1
B
A
f1
5/23/2016
g1
AOO
61
Connection to software
architecture
Advantages of ports: Components are
separated from connections. Can reuse
components with new connections without
having to modify components.
B
A{void f(){b.g1();}}
// connect A.g1 B.f1
A
f1
5/23/2016
AOO
g1
62
Connection to software
architecture
A{void f(){b.g1();}} B{void f1() {…}
// connect A.g1 B.f1
void f2() {…}}
// connect A.g1 B.f2
connections=adapters
B
// can call other method
A
f1
// in A without
f2
// changing A or B
g1
5/23/2016
AOO
63
Connection to software
architecture
Disadvantages of ports:
Need to write more.
A{void f(){b.g1();}} B{void f1() {…}
// connect A.g1 B.f1
void f2() {…}}
B
A
f1
// connect A.g1 B.f2
f2
g1
5/23/2016
AOO
64
Cycle checking example
• Growth plan consists of two steps:
– Depth-first traversal visitor
– Cycle checking visitor
5/23/2016
AOO
65
DFS tree
1
2
6
3
7
4
5
5/23/2016
AOO
66
Visitors for graph algorithms
StrategyType1={
Graph -> Adjacency
Adjacency -> intermed:Vertex
Vertex -> Adjacency
}
5/23/2016
AOO
67
Visitors for graph algorithms
GenericDFT
(StrategyType1 s){
s.intermed{
change
(@
this.doSomething();
next(); @)
5/23/2016
AOO
68
Visitors for graph algorithms
void doSomething();
}//s.intermediate
s.target {
boolean mark;
init (@ mark = false; @)
change (@ if (!mark)
{mark=true; next()}; @)
}
}
5/23/2016
AOO
69
Visitors for graph algorithms
GenericCycleCheck{
Stack stack;
init (@ stack=new Stack(); @)
s.target{
change (@
if (stack.include(this)
print(“cycle found”);
else { stack.push(this);
next(); stack.pop();} @)
} modifies GenericDFT;
5/23/2016
AOO
70
Print vertices
GenericPrintingDFT extends
GenericDFT {
s.interm {
doSomething()
{this.print()}
}
}
5/23/2016
AOO
71
Visitors for graph algorithms
s1={
Graph -> Adjacency
Adjacency -> intermed:Vertex
through ->*,neighbors,*
Vertex -> Adjacency
through <- *,source,* }
5/23/2016
AOO
72
Use
s1 = // previous view graph
Graph {
dft() is GenericDFT(s1);
dftPrint() is
GenericPrintingDFT(s1);
cycleCheck() is
GenericCycleCheck(s1);}
5/23/2016
AOO
73
Finding connected components
2
3
1
2
3
1
1
3 connected components
5/23/2016
AOO
74
Using strategy edge
ConnectivityVisitor {
int compNumber;
init (@ compNumber=0; @)
s.source {
change (@ next();
print(compNumber);}
5/23/2016
AOO
75
Using strategy edge
ConnectivityVisitor {…
s.source->s.target {
s.target.newConnComp();}
s.target {
newConnComp(){
compNumber+=1;}
} modifies GenericDFT
5/23/2016
AOO
76
Overview
dft
call
visitor
attachment
Dft
CycleCheck
uncondDft
5/23/2016
UncondDft
AOO
77
Overview
dft
adaptive
method
Dft
call
visitor
attachment
uncondDft
5/23/2016
UncondDft
AOO
CycleCheck
78
adaptive
method
Overview
dft
call
visitor
attachment
Dft
Adjacency:s
Unmarked:t
uncondDft
UncondDft
Adjacency:s
Vertex
Adjacency:t
CycleCheck
Adjacency:s
5/23/2016
AOO
79
Depth-first traversal
Adjacency {
void dft(Graph g)
s = from a:Adjacency to Unmarked
(Dft(s,g,a))}
Dft(Strategy s, Graph g, Adjacency a) {
s.source
Mark marked; //Mark: Marked|Unmarked.
s.target change(g)
a.print(); … ; a.uncondDft(g); }
5/23/2016
AOO
80
Class graph for visitors
Mark: Marked|Unmarked.
is the class graph of the Dft visitor. Each
visitor might have its own class graph. The
classes in the graph serve only the purposes
of that visitor.
Mark marked becomes a temporary field of
Adjacency.
5/23/2016
AOO
81
Arguments to a visitor
• strategies
• class-valued variables
• relation-valued variables
– method-valued variables
• base objects of class-valued variable type
(e.g., Graph)
5/23/2016
AOO
82
Depth-first traversal
Adjacency {
void uncondDft(Graph g)
s = through ->*,neighbors,*
via Vertex
to-stop Adjacency
UncondDft(s,g)}
5/23/2016
AOO
83
Traversal through derived edge
• The traversal back to Adjacency goes
through a derived edge called find which
is added only for this task to the class graph.
5/23/2016
AOO
84
Depth-first traversal
UncondDft(Strategy s,Graph g) {
Vertex
Adjacency find //derived
implemented by
g.find(host);
s.target
change host.dft();next();}
5/23/2016
AOO
85
Depth-first traversal
Vertex
Adjacency find //derived
implemented by
g.find(host);
find is temporarily in the class graph and
when find is traversed the code in the
implementation is executed.
5/23/2016
AOO
86
Find
Graph {
Adjacency find(Vertex v)
s = to Adjacency {//inlined
s.target change
if (v.equals(source)){
return_val=host;
s.exitTraversal();}}}
5/23/2016
AOO
87
Exiting a traversal
• s.ExitTraversal() is a useful method
to get out of a traversal in a structure-shy
way. Might result in getting out of several
loops.
5/23/2016
AOO
88
adaptive
method
Overview
dft
call
visitor
attachment
Dft
Adjacency:s
Unmarked:t
uncondDft
UncondDft
Adjacency:s
Vertex
Adjacency:t
CycleCheck
Adjacency:s
5/23/2016
AOO
89
Cycle checking
Adjacency {
s = from Adjacency
to Unmarked;
void dft(Graph g) is
CycleCheck(s)
modifies Dft(s,g)}
5/23/2016
AOO
90
Cycle checking
CycleCheck(Strategy s) { Stack st;
init st = new Stack();
s.source change
st.push(host);
if (st.containsDuplicate(host))
st.print(); //cycle found
next();
st.pop();
}
5/23/2016
AOO
91
Adaptive Programming
strategy types
strategies
visitor types
visitors
Java program
aspect descriptions
5/23/2016
class graph types
class graphs
AOO
92
Adaptive Programming
strategy types(class graph types)
strategies(class graphs)
visitor types(strategy types)
visitors(strategies)
Java program
aspect descriptions
5/23/2016
class graph types
class graphs
AOO
93
The modifies relationship:
higher-level than part-of
C
I
S
this.get_s().get_total();
C
I
d
5/23/2016
S
s
AOO
94
Modifies versus part-of
• Part-of advantages
– close to Java, no new syntax
• Modifies advantages
– separation of components and connections
– only “main” visitor needs to be given to
traversal
– modification has flavor of incremental
inheritance, before/after/around -> around
5/23/2016
AOO
95
Modifies versus part-of
• Modifies advantages
– no need to change class dictionary to use
different composition of visitors, dynamic
composition
5/23/2016
AOO
96
Building visitors
• inheritance between visitor classes
– overriding
• modify relationships between visitor classes
– incremental
• connections between visitor classes
– specified with modification relationships
– refer to ports
5/23/2016
AOO
97
Visitor objects as conceptual aid
• visitor objects walk around on host objects
• visitor objects have their own storage
• host/visitor distinction is useful
Implementation does not have to be in terms
of visitor objects. Insert code into classes
and pass visitor information as argument.
5/23/2016
AOO
98
Modification and host/visitor
!
to host
?
from host
table
!V to visitor V
C
Check
before
Container
after
before
Weight
5/23/2016
I
Initial
S
?V
from visitor V
Sum
?S(Sr),!I
?,?I(Ir),!C(Cr)
?S(Sr),!I(Ir)
?,!S(Sr)
AOO
99
before: Host/visitor table
visitors
Check
before
Container
after ?,?I,!C
before
Weight
5/23/2016
Initial
Sum
?S,!I
?S,!I
?,!S
AOO
!
?
!V
?V
to host
from host
to visitor V
from visitor V
100
Modifies relationship examples
C
Average
I
S
Count
CycleCheck
UncondDft
Sum
5/23/2016
AOO
101
Multiple visitors
V1{
void f()
s=…
V2
V3
V4}
V1{
void f()
s=…
V2 modifies
V3 modifies
V4}
is equivalent to
5/23/2016
AOO
102
How to simulate the modification
relationship in Demeter/Java
• use part-of relationship between visitor
classes
• use multiple visitors with the same traversal
• instead of using ports, access parts in
adjacent visitor
• instantiate visitor objects and connect them
• cannot have subtraversals
5/23/2016
AOO
103
What is missing in
Demeter/Java?
•
•
•
•
extend adaptive method syntax
introduce modifies relationship
support for strategy types
talk about traversal dependent behavior in
visitor; s.source = s.target etc.
• s.exitTraversal()
• subtraversals?
5/23/2016
AOO
104
What is missing in
Demeter/Java?
• around implementation: must be corrected
• name combinations of visitors for reuse
5/23/2016
AOO
105
Summary
• Visitors as components are a useful
approach towards building flexible software
components
• Visitors are better components than classes:
they involve a group of classes
5/23/2016
AOO
106
Final slide
5/23/2016
AOO
107
Component coupling in
Demeter/Java
• S-F coupling
– strategies don’t refer to visitor classes directly
but they are coupled through a common class
dictionary
– visitor classes refer to strategies through a
common set of class names
– strategies refer to “task-important” classes also
used in visitor classes
5/23/2016
AOO
108
SummingVisitor (Strategy s,
Method f) { …
s.target
change
(@ total_sum += host.f();
next(); @)
Warning: new syntax,
s.source
not implemented
change
(@ /* before traversal */
next(); @)
/* after traversal */}
5/23/2016
AOO
109
Strategy passing by name and
others positional
Warning: new syntax,
• Container {
not implemented
s1 = to Weight;
int check() s=s1 by
Checking s=s1(get_capacity)
modifies
Initial s=s1()
modifies
Summing s=s1(value)}
5/23/2016
AOO
110
Strategy passing by name
Warning: new syntax,
not implemented
• Container {
s1 = to Weight;
int check() s=s1 by
Checking s=s1 f=get_capacity
modifies
Initial s=s1
modifies
Summing s=s1 f=value}
5/23/2016
AOO
111
Strategy passing by name,
explicit connection
• int check() s=s1 by
Checking f=get_capacity
modifies
Warning: new syntax,
Initial
not implemented
modifies
Summing f=value
connect Checking.in Initial.out
Initial.in Summing.out
5/23/2016
AOO
112
Parameter passing by name,
explicit connection
• int check() s=s1 by
Checking f=get_capacity
in=Initial.out
modifies
Initial in=Summing.out
modifies
Summing f=value
preferred way to connect: Ada style
allows multiple visitors to influence
same visitor.
Warning: new syntax,
not implemented
5/23/2016
AOO
113
Compose and name visitors
• ContainerChecking() = // visitor class
Checking f=get_capacity
in=Initial.out
modifies
Initial in=Summing.out
modifies
Summing f=value
preferred way to connect: Ada style
allows multiple visitors to influence
same visitor.
Warning: new syntax,
not implemented
5/23/2016
AOO
114
Linearize modification hierarchy
• Similar to linearization of multiple inheritance
hierarchies
• what is meaning of next()?
• Average,Count,Sum Average
Count
• Average,Sum,Count !
• Dft based on order
given by programmer
5/23/2016
AOO
Sum
115
Cycle checking/alternative?
Adjacency {
void cycleCheck(Graph g)
this.dft(g)
modified by CycleCheck
}
5/23/2016
AOO
116