Converting from Immutable to Mutable Objects CS 5010 Program Design Paradigms "Bootcamp" Lesson 11.4 © Mitchell Wand, 2012-2014 This work is licensed under.

Slides:



Advertisements
Similar presentations
When do I need an invariant? CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.4 TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Advertisements

Real State vs. Simulated State CS 5010 Program Design Paradigms "Bootcamp" Lesson 11.3 © Mitchell Wand, This work is licensed under a Creative.
Basics of Inheritance CS 5010 Program Design Paradigms "Bootcamp" Lesson 12.1 © Mitchell Wand, This work is licensed under a Creative Commons.
Testing Simple Objects CS 5010 Program Design Paradigms "Bootcamp" Lesson 10.6 © Mitchell Wand, This work is licensed under a Creative Commons.
Patterns of Interaction 2: Publish-Subscribe CS 5010 Program Design Paradigms "Bootcamp" Lesson 11.6 © Mitchell Wand, This work is licensed under.
Midterm Review CS 5010 Program Design Paradigms “Bootcamp” Lesson 9.4 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Interfaces CS 5010 Program Design Paradigms "Bootcamp" Lesson 10.2 © Mitchell Wand, This work is licensed under a Creative Commons Attribution-NonCommercial.
Linear Search CS 5010 Program Design Paradigms “Bootcamp” Lesson 9.1 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Classes, Objects, and Methods CS 5010 Program Design Paradigms "Bootcamp" Lesson 10.1 © Mitchell Wand, This work is licensed under a Creative.
Function Composition CS 5010 Program Design Paradigms “Bootcamp” Lesson © Mitchell Wand, This work is licensed under a Creative Commons.
Structural Decomposition CS 5010 Program Design Paradigms “Bootcamp” Lesson 2.1 © Mitchell Wand, This work is licensed under a Creative Commons.
Stateful Objects and Stable Identities CS 5010 Program Design Paradigms "Bootcamp" Lesson 11.2 © Mitchell Wand, This work is licensed under a.
Introducing General Recursion CS 5010 Program Design Paradigms “Bootcamp” Lesson 8.2 TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Mutually-Recursive Data Definitions CS 5010 Program Design Paradigms “Bootcamp” Lesson 6.4 © Mitchell Wand, This work is licensed under a Creative.
Foldr CS 5010 Program Design Paradigms “Bootcamp” Lesson 5.4 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAA © Mitchell.
Patterns of Communication Between Objects CS 5010 Program Design Paradigms "Bootcamp" Lesson 11.1 © Mitchell Wand, This work is licensed under.
Solving Your Problem by Generalization CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.1 © Mitchell Wand, This work is licensed under a.
Examining Two Pieces of Data CS 5010 Program Design Paradigms “Bootcamp” Lesson © Mitchell Wand, This work is licensed under a Creative.
Classes, Objects, and Methods CS 5010 Program Design Paradigms "Bootcamp" Lesson 10.1 © Mitchell Wand, This work is licensed under a Creative.
Testing Mutable Objects CS 5010 Program Design Paradigms "Bootcamp" Lesson 11.5 © Mitchell Wand, This work is licensed under a Creative Commons.
The Design Recipe using Classes CS 5010 Program Design Paradigms "Bootcamp" Lesson 10.5 © Mitchell Wand, This work is licensed under a Creative.
Design Strategies 3: Divide into cases CS 5010 Program Design Paradigms “Bootcamp” Lesson © Mitchell Wand, This work is licensed under.
Using Inheritance to Share Implementations CS 5010 Program Design Paradigms "Bootcamp" Lesson 12.1 © Mitchell Wand, This work is licensed under.
Generalizing Similar Functions CS 5010 Program Design Paradigms “Bootcamp” Lesson 5.1 TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Rewriting your function using map and foldr CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual.
Two Draggable Cats CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete this.
More examples of invariants CS 5010 Program Design Paradigms “Bootcamp” Lesson © Mitchell Wand, This work is licensed under a Creative.
Generalizing Over Functions CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Model-View-Controller Architecture CS 5010 Program Design Paradigms “Bootcamp” Lesson © Mitchell Wand, This work is licensed under a Creative.
A Case Study: Space Invaders CS 5010 Program Design Paradigms "Bootcamp" Lesson © Mitchell Wand, This work is licensed under a Creative.
Testing Objects CS 5010 Program Design Paradigms "Bootcamp" Lesson © Mitchell Wand, This work is licensed under a Creative Commons Attribution-NonCommercial.
Patterns of Interaction 2: Publish-Subscribe CS 5010 Program Design Paradigms "Bootcamp" Lesson © Mitchell Wand, This work is licensed.
Searching in a Graph CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete this.
Solving Your Problem by Generalization CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.1 © Mitchell Wand, This work is licensed under a.
The Design Recipe using Classes CS 5010 Program Design Paradigms "Bootcamp" Lesson © Mitchell Wand, This work is licensed under a Creative.
Callbacks and Interacting Objects CS 5010 Program Design Paradigms "Bootcamp" Lesson © Mitchell Wand, This work is licensed under a Creative.
Testing Mutable Objects CS 5010 Program Design Paradigms "Bootcamp" Lesson © Mitchell Wand, This work is licensed under a Creative Commons.
Generalizing this Design CS 5010 Program Design Paradigms "Bootcamp" Lesson © Mitchell Wand, This work is licensed under a Creative Commons.
The DD  OO Recipe CS 5010 Program Design Paradigms "Bootcamp" Lesson 10.4 © Mitchell Wand, This work is licensed under a Creative Commons Attribution-NonCommercial.
Halting Measures and Termination Arguments CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual.
Non-Empty Lists CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Stateful Objects and Stable Identities CS 5010 Program Design Paradigms "Bootcamp" Lesson © Mitchell Wand, This work is licensed under.
The Last Lecture CS 5010 Program Design Paradigms "Bootcamp" Lesson © Mitchell Wand, This work is licensed under a Creative Commons Attribution-NonCommercial.
Using Inheritance to Share Implementations CS 5010 Program Design Paradigms "Bootcamp" Lesson © Mitchell Wand, This work is licensed under.
Using the List Template CS 5010 Program Design Paradigms “Bootcamp” Lesson 4.2 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this.
More linear search with invariants CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before.
Midterm Review CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Solving Your Problem by Generalization CS 5010 Program Design Paradigms “Bootcamp” Lesson © Mitchell Wand, This work is licensed under.
Converting from Immutable to Mutable Objects CS 5010 Program Design Paradigms "Bootcamp" Lesson © Mitchell Wand, This work is licensed.
Classes, Objects, and Interfaces CS 5010 Program Design Paradigms "Bootcamp" Lesson © Mitchell Wand, This work is licensed under a Creative.
CS 5010 Program Design Paradigms "Bootcamp" Lesson 9.4
Introduction to Invariants
Reviewing your Program
CS 5010 Program Design Paradigms “Bootcamp” Lesson 6.2
Generalizing this Design
CS 5010 Program Design Paradigms “Bootcamp” Lesson 5.1
Callbacks and Interacting Objects
CS 5010 Program Design Paradigms "Bootcamp" Lesson 9.3
Patterns of Interaction 2: Publish-Subscribe
Patterns of Interaction 2: Publish-Subscribe
Solving Your Problem by Generalization
A Case Study: Space Invaders
Generalizing Similar Functions
The Iterative Design Recipe
CS 5010 Program Design Paradigms "Bootcamp" Lesson 12.1
Examining Two Pieces of Data
A Case Study: Space Invaders
When do I need an invariant?
Presentation transcript:

Converting from Immutable to Mutable Objects CS 5010 Program Design Paradigms "Bootcamp" Lesson 11.4 © Mitchell Wand, This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. Creative Commons Attribution-NonCommercial 4.0 International License 1

Key Points for Lesson 11.4 Void means that the function can return any value it wants, so the caller must ignore the returned value. A function that has a Void return contract must have an EFFECT, so we must document this as part of the purpose statement. Transform a method definition that produces a new object into one that alters this object by doing a set! on the fields that should change. This is the only acceptable use of set! in this course. 2

Video Demonstration: stateful-box.rkt yys (7:30) yys 3

The Void transformation: contracts Key contract (in Box%): on-mouse : Integer Integer MouseEvent -> Void Void means that the function can return any value it wants. The caller of the function can’t rely on it returning any meaningful value So the caller must ignore the returned value 4

If we don’t return a useful value, then what? A function that has a Void return contract must have an EFFECT. Must document this as part of the purpose statement: 5

Example of an EFFECT in a purpose statement ;; adjust-width : Number -> Void ;; EFFECT: adjusts the center and ;; width of this box so that the ;; width is new-width and the left ;; edge is unchanged 6

Transforming the method definition We can change a function that produces a new object into one that alters this object by doing a set! on the fields that should change. Often this is only a small subset of the fields, so the new code is considerably shorter than the old one. When we do this, the new function no longer produces a meaningful value, so whoever calls it can no longer rely on its value. This is the meaning of the Void contract. In other languages, Void means that the method returns no value at all. In Racket, every function returns some value, so we use Void to mean a value that we don’t know and don’t care about. We sometimes call this code “imperative”, because it deals in commands rather than values. 7

The Void transformation: function definition (define (adjust-width new-width) ;; (new Box% ;; [x (+ (send this left-edge) ;; (/ new-width 2))] ;; [y y] ;; [w new-width] ;; [h h] ;; [objects objects] ;; [selected? selected?]) (set! x (+ (send this left-edge) (/ new-width 2))) (set! w new-width)) We change a function that produces a new box into one that alters this object by doing a set! on the fields that should change. 8

x = 250 w = 100 (right-edge) => 300 x = 220 box = x = 225 box = (send world after-tick) = (new World% [box (begin (send box after-tick) box)] [ball (send ball after-tick)]) world (send after-tick) World-after-tick in stateful-box.rkt The world always has same box INVARIANT: the world’s ball always points to the world’s box 9

x = 250 w = 100 (right-edge) => 300 x = 220 box = (new World% [box (begin (send box after-mouse...) box] [ball (send ball after-mouse...)]) world World after drag in stateful-box.rkt x = 252 w = 104 (right-edge) => 306 The world always has same box ball after-mouse returns itself INVARIANT: the world’s ball always points to the world’s box WIN! 10

Next step: a list of balls Now let's have a list of balls instead, Keystroke "n" creates a new ball. Plan: 1. First, we'll write an add-object method in our world. 2. Then, we'll add a ball factory to the world. The ball factory will know about the world and the box, and on an "n" it will add a ball by calling the add-object method on the world. But wait: the factory needs to know about the world, so it can send it add-object messages. So this means the world must have identity: it must be stateful. So before we do anything else, let's just make the world stateful. 11

Video Demonstration: stateful-world.rkt eOo (7:52) eOo 12

x = 250 w = 100 (right-edge) => 300 x = 220 box = x = 225 box = (send world after-tick) = (begin (send box after-tick) (set! ball (send ball after-tick))) world (send after-tick) World-after-tick in stateful-world.rkt INVARIANT: the world’s ball always points to the world’s box 13

x = 250 w = 100 (right-edge) => 300 x = 220 box = world World after drag in stateful-world.rkt x = 252 w = 104 (right-edge) => 306 ball on-mouse returns itself INVARIANT: the world’s ball always points to the world’s box WIN! (send world on-mouse...) = (begin (send box on-mouse...) (set! ball (send ball on-mouse...))) 14

Video Demonstration: ball-factory.rkt Next, we’ll add a ball factory to the world. This is a special purpose StatefulWorldObject that processes keystrokes and adds objects to the world. oqU oqU 15

x = 250 w = 100 (right-edge) => 300 x = 20 box = world Building the initial world in ball- factory.rkt INVARIANT: the world’s ball always points to the world’s box WIN! world = box = 16

Key Points for Lesson 11.4 Void means that the function can return any value it wants, so the caller must ignore the returned value. A function that has a Void return contract must have an EFFECT, so we must document this as part of the purpose statement. Transform a method definition that produces a new object into one that alters this object by doing a set! on the fields that should change. 17

Next Steps Study stateful-box.rkt, stateful-world.rkt, and ball-factory.rkt in the Examples folder. If you have questions about this lesson, ask them on the Discussion Board Do Guided Practice 11.1 Go on to the next lesson. 18