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 1/10/2022 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? 1/10/2022 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) 1/10/2022 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. 1/10/2022 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 1/10/2022 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 1/10/2022 AOO 6

Environmental affect on a 1 Classes C 3 C 2 C 1 1/10/2022 Objects C 3 shared features a 3 a 2 C 2 shared features a 1 C 1 particular features C 2 particular features C 1 shared features C 3 particular features AOO 7

Application domains • There abundant cases of containment hierarchies where contained objects have different behaviors depending on their surrounding environment. 1/10/2022 AOO 8

Environmental Acquisition • methods Class. Def{// Concrete acquires print void pc() to Concrete { (@ Class. Def c; @) before Class. Def (@ c=host; @) before Concrete (@ c. print(); @)} 1/10/2022 AOO 9

Example: UML class diagram Class. Graph 0. . * Entry entries Class. Graph Class. Def BParse Body parts Part class. Name 0. . * super Class. Name Concrete 1/10/2022 EParse Note: we use a thick arrow to denote inheritance. UML uses an open arrow. Abstract AOO 10

Example: UML class diagram Class. Graph 0. . * Entry entries Class. Graph Class. Def BParse Body parts Part class. Name 0. . * super Class. Name Concrete 1/10/2022 EParse 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 1/10/2022 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 acq. Size = 20 /* default */; @) before Chapter (@ acq. Size=… ; @) before Section (@ acq. Size=… ; @) before Character (@ /* print with acq. Size */ @) 1/10/2022 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. 1/10/2022 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 1/10/2022 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. 1/10/2022 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 1/10/2022 AOO 17

Kinships between classes • May kinship – a class C 1 may be contained in a class C 2 • There is at least one path from C 2 to C 1 • Must kinship – a class C 1 must be contained in a class C 2 • AP provides a containment path concept to deal with kinships along which acquisition takes place. 1/10/2022 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 1/10/2022 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. 1/10/2022 AOO 20

Context Switch • Better separation of concerns in AP 1/10/2022 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. 1/10/2022 AOO 22

Components of AP C Should not refer to each other directly 1/10/2022 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 1/10/2022 S C<->C F<->F F AOO 24

Composition of visitors, strategies and class graphs Generic visitors Strategy types gv 1 gv 2 st 1 s 1 = instantiation of st 1 for CG 1 gv 2(gv 1)(s 1 CG 1) 1/10/2022 instantiated behavior s 1 st 1 Class graphs gv 1 CG 2 gv 2 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 1/10/2022 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. 1/10/2022 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 1/10/2022 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. 1/10/2022 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) 1/10/2022 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. 1/10/2022 AOO 31

Structure of a generic visitor generic. Mod. Visitor(Strategy s, Method m 1, …, mk){ //variables global for traversal init()… return()… start()… final()… s. source //variables that temp. extend host object init()… change() host. m 1(); … next. return; … next(); host. local. Method 1(); … local. Method 1()(@ … @); … }// end of visitor 1/10/2022 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) 1/10/2022 AOO 33

Composition of visitors, strategies and class graphs Generic visitors Strategy types gv 1 gv 2 st 1 s 1 = instantiation of ST 1 for CG 1 gv 2(gv 1)(s 1 CG 1) 1/10/2022 instantiated behavior s 1 st 1 Class graphs gv 1 CG 2 gv 2 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 1/10/2022 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. 1/10/2022 AOO 36

C 1 Components of AP C 2 S C interface Should not refer to each other directly 1/10/2022 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. 1/10/2022 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 1/10/2022 AOO Middle to End C to D 39

C 1 Components of AP C 2 S 1 C interface Should not refer to each other directly 1/10/2022 S interface F AOO S 2 40

Reduce coupling between visitors • Visitor has a signature: – provided – required 1/10/2022 AOO 41

Visitor classes as components return visitor class strategy s class graph Initial. Visitor Summing. Visitor return total diff sum what? get_value 1/10/2022 Checking. Visitor check what? get_capacity AOO 42

Container capacity problem • need to sum: use Summing. Visitor • need to check: use Checking. Visitor • want to do it in one traversal: need to store sum when container is entered: Initial. Visitor 1/10/2022 AOO 43

Earlier approach • In an earlier solution, we nested the three visitor classes; now we use another dynamic relationship between them: modification relationship. 1/10/2022 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 1/10/2022 AOO 45

Container capacity problem • Checking. Visitor – data member: violations – after each container, check whether difference of sum at the end and the beginning (Initial. Visitor) of a container is larger than capacity – uses Initial. Visitor (difference) 1/10/2022 AOO 46

Container capacity problem • Initial. Visitor – store sum at beginning (Summing. Visitor) of container – return difference beginning-end upon request – uses Summing. Visitor 1/10/2022 AOO 47

Reduced coupling Warning: new syntax, not implemented • Container { s 1 = to Weight; int check() by Checking(s 1, get_capacity) modifies Initial(s 1) modifies Summing(s 1, value)} 1/10/2022 AOO 48

Where to define visitor classes? • not in class graph • in separate visitor files *. vis or “inlined” in *. beh files. • generic. vis (Print. Visitor, Copy. Visitor, …) • visitor library for each application domain – statistics (Sum, Count, Average, …) – graph algorithms (Dft, Cycle. Check, …) 1/10/2022 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 1/10/2022 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 1/10/2022 AOO 51

Reduced coupling, alternative syntax Warning: new syntax, not implemented • Container { s 1 = to Weight; int check() do s 1 by Checking(*, get_capacity) modifies Initial(*) modifies Summing(*, value)} 1/10/2022 AOO 52

Reduced coupling Warning: new syntax, not implemented • Company { s 1 = to Salary; float average. Sal() do s 1 by Average //2 next visitors modifies Summing f=value, Counting} 1/10/2022 AOO 53

Average Visitor Average (Strategy s 1) { s 1. source change /* old around */ (@ next(); int s = Summing. return(); int c = Counting. return(); @) return (@ s/c @) } return Summing 1/10/2022 AOO Average 54

Modifies relationship examples C Average I S Count Cycle. Check Uncond. Dft Sum 1/10/2022 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 1/10/2022 AOO 56

Summing. Visitor (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(); @)} 1/10/2022 AOO 57

Initial. Visitor (Strategy s) { s. source /* old around */ int initial; change (@ initial = next. return(); next(); @) return (@ next. return() -initial @) } 1/10/2022 AOO 58

Checking. Visitor (Strategy s, Method f) { int violations; init (@ violations = 0; @) s. source(s) change (@ next(); if (next. return() > host. f()) …@) return (@ violations @)} 1/10/2022 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 connector 1/10/2022 AOO 60

Connection to software architecture • Components with input/output ports • Connectors between ports A{void f(){b. f 1(); }} A{void f(){b. g 1(); }} // in: B. f 1() out: A. f() // connect A. g 1 B. f 1 B A f 1 1/10/2022 g 1 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. g 1(); }} // connect A. g 1 B. f 1 A f 1 1/10/2022 AOO g 1 62

Connection to software architecture A{void f(){b. g 1(); }} // connect A. g 1 B. f 1 B{void f 1() {…} void f 2() {…}} // connect A. g 1 B. f 2 connections=adapters B // can call other method A f 1 // in A without f 2 // changing A or B g 1 1/10/2022 AOO 63

Connection to software architecture Disadvantages of ports: Need to write more. A{void f(){b. g 1(); }} B{void f 1() {…} // connect A. g 1 B. f 1 void f 2() {…}} B // connect A. g 1 B. f 2 A f 1 f 2 g 1 1/10/2022 AOO 64

Cycle checking example • Growth plan consists of two steps: – Depth-first traversal visitor – Cycle checking visitor 1/10/2022 AOO 65

DFS tree 1 2 6 3 4 1/10/2022 7 5 AOO 66

Visitors for graph algorithms Strategy. Type 1={ Graph -> Adjacency -> intermed: Vertex -> Adjacency } 1/10/2022 AOO 67

Visitors for graph algorithms Generic. DFT (Strategy. Type 1 s){ s. intermed{ change (@ this. do. Something(); next(); @) 1/10/2022 AOO 68

Visitors for graph algorithms void do. Something(); }//s. intermediate s. target { boolean mark; init (@ mark = false; @) change (@ if (!mark) {mark=true; next()}; @) } } 1/10/2022 AOO 69

Visitors for graph algorithms Generic. Cycle. Check{ Stack stack; init (@ stack=new Stack(); @) s. target{ change (@ if (stack. include(this) print(“cycle found”); else { stack. push(this); next(); stack. pop(); } @) } modifies Generic. DFT; 1/10/2022 AOO 70

Print vertices Generic. Printing. DFT extends Generic. DFT { s. interm { do. Something() {this. print()} } } 1/10/2022 AOO 71

Visitors for graph algorithms s 1={ Graph -> Adjacency -> intermed: Vertex through ->*, neighbors, * Vertex -> Adjacency through <- *, source, * } 1/10/2022 AOO 72

Use s 1 = // previous view graph Graph { dft() is Generic. DFT(s 1); dft. Print() is Generic. Printing. DFT(s 1); cycle. Check() is Generic. Cycle. Check(s 1); } 1/10/2022 AOO 73

Finding connected components 2 3 1 1 3 connected components 1/10/2022 AOO 74

Using strategy edge Connectivity. Visitor { int comp. Number; init (@ comp. Number=0; @) s. source { change (@ next(); print(comp. Number); } 1/10/2022 AOO 75

Using strategy edge Connectivity. Visitor {… s. source->s. target { s. target. new. Conn. Comp(); } s. target { new. Conn. Comp(){ comp. Number+=1; } } modifies Generic. DFT 1/10/2022 AOO 76

Overview dft call visitor attachment Dft Cycle. Check uncond. Dft 1/10/2022 Uncond. Dft AOO 77

Overview dft adaptive method Dft call visitor attachment uncond. Dft 1/10/2022 Uncond. Dft AOO Cycle. Check 78

adaptive method Overview dft Dft call visitor attachment Adjacency: s Unmarked: t uncond. Dft Uncond. Dft Adjacency: s Vertex Adjacency: t Cycle. Check Adjacency: s 1/10/2022 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. uncond. Dft(g); } 1/10/2022 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. 1/10/2022 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) 1/10/2022 AOO 82

Depth-first traversal Adjacency { void uncond. Dft(Graph g) s = through ->*, neighbors, * via Vertex to-stop Adjacency Uncond. Dft(s, g)} 1/10/2022 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. 1/10/2022 AOO 84

Depth-first traversal Uncond. Dft(Strategy s, Graph g) { Vertex Adjacency find //derived implemented by g. find(host); s. target change host. dft(); next(); } 1/10/2022 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. 1/10/2022 AOO 86

Find Graph { Adjacency find(Vertex v) s = to Adjacency {//inlined s. target change if (v. equals(source)){ return_val=host; s. exit. Traversal(); }}} 1/10/2022 AOO 87

Exiting a traversal • s. Exit. Traversal() is a useful method to get out of a traversal in a structure-shy way. Might result in getting out of several loops. 1/10/2022 AOO 88

adaptive method Overview dft Dft call visitor attachment Adjacency: s Unmarked: t uncond. Dft Uncond. Dft Adjacency: s Vertex Adjacency: t Cycle. Check Adjacency: s 1/10/2022 AOO 89

Cycle checking Adjacency { s = from Adjacency to Unmarked; void dft(Graph g) is Cycle. Check(s) modifies Dft(s, g)} 1/10/2022 AOO 90

Cycle checking Cycle. Check(Strategy s) { Stack st; init st = new Stack(); s. source change st. push(host); if (st. contains. Duplicate(host)) st. print(); //cycle found next(); st. pop(); } 1/10/2022 AOO 91

Adaptive Programming strategy types strategies visitor types visitors Java program aspect descriptions 1/10/2022 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 1/10/2022 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 1/10/2022 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 1/10/2022 AOO 95

Modifies versus part-of • Modifies advantages – no need to change class dictionary to use different composition of visitors, dynamic composition 1/10/2022 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 1/10/2022 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. 1/10/2022 AOO 98

Modification and host/visitor ! to host ? from host table !V to visitor V C 1/10/2022 I AOO S ? V from visitor V 99

before: Host/visitor table hosts visitors 1/10/2022 AOO ! ? !V ? V to host from host to visitor V from visitor V 100

Modifies relationship examples C Average I S Count Cycle. Check Uncond. Dft Sum 1/10/2022 AOO 101

Multiple visitors V 1{ void f() s=… V 2 V 3 V 4} V 1{ void f() s=… V 2 modifies V 3 modifies V 4} is equivalent to 1/10/2022 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 1/10/2022 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. exit. Traversal() • subtraversals? 1/10/2022 AOO 104

What is missing in Demeter/Java? • around implementation: must be corrected • name combinations of visitors for reuse 1/10/2022 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 1/10/2022 AOO 106

Final slide 1/10/2022 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 1/10/2022 AOO 108

Summing. Visitor (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 */} 1/10/2022 AOO 109

Strategy passing by name and others positional Warning: new syntax, • Container { not implemented s 1 = to Weight; int check() s=s 1 by Checking s=s 1(get_capacity) modifies Initial s=s 1() modifies Summing s=s 1(value)} 1/10/2022 AOO 110

Strategy passing by name Warning: new syntax, not implemented • Container { s 1 = to Weight; int check() s=s 1 by Checking s=s 1 f=get_capacity modifies Initial s=s 1 modifies Summing s=s 1 f=value} 1/10/2022 AOO 111

Strategy passing by name, explicit connection • int check() s=s 1 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 1/10/2022 AOO 112

Parameter passing by name, explicit connection • int check() s=s 1 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 1/10/2022 AOO 113

Compose and name visitors • Container. Checking() = // 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 1/10/2022 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 1/10/2022 AOO Sum 115

Cycle checking/alternative? Adjacency { void cycle. Check(Graph g) this. dft(g) modified by Cycle. Check } 1/10/2022 AOO 116