Design Patterns for Lazy Evaluation Ning Zhu Jan 22 2016

What is Lazy Evaluation Concept Expression is only evaluated when it's "actually needed” Application/Implementation Often represented in functional programming Why do it in OO? Practically useful -> ⬇ space complexity Good practice/demo for abstract thinking

How to do LE in OO? Design Goals Design Methods Example (Pros & Cons)

Design goal -Flexible, Extendible, Reuseable the LE structure (e.g. LRS) appears as if it has all the elements, to all algos the first and the rest can transit from lazy to eager misc: the evaluated portion performs as efficient as a regular eager structure No modification or recompilation for existing code  Existing algorithms behave the same for ordinary finite structure and lazy structure Because it’s dynamic re-classification -> state pattern

Design: Goals  Methods The invariant: Runtime change of behaviors: lazy -> eager Not known to the outside world ⬇ Dynamic re-classification State Design Pattern the LE structure (e.g. LRS) appears as if it has all the elements, to all algos the first and the rest can transit from lazy to eager  misc: the evaluated portion performs as efficient as a regular eager structure how to design, what to choose? Find the invariant and the unique thing of lazy evaluation => a behavior of transition => behaviorally different, not known to the outside world

Design: Methods Lazy->Eager, a state transition in State Design Pattern LRS: behaviorally similar (transition across states from element to element) -> good candidate for modifying Minimal change = Add a LazyState? \ Invariant: transitioning Variant: the way the transition LRS: Empty to Non-Empty (Eager) LazyEval: LazyNonE -> NonE

Lazy->Eagar Specific Further Design Delegate LE-specific transitioning (variant) to state LRStruct IAlgo Lazy->Eagar Specific Decorator/Wrapper IAlgo has no nextLRS, be verbatim! jumped over how to do decorator, wrong! don't jump over logic links! the steps will suggest what design to use for the next step Regular LRStruct behavior /operation

Get the rest of LRS----> get a LRS (Lazy) End of Design? No… Minimal change of existing framework (e.g. LRStruct) -> Good OO design != let client play with encapsulated constructor Get the rest of LRS----> get a LRS (Lazy)

End of Design? No… Minimal change of existing framework (e.g. LRStruct) Good OO design Information hiding Factory: This is a finite factory

Example- Create a list of prime numbers with Sieve’s Algo Demo

Overview Lazy Evaluation Flexible Reuseable Extendible Factory No need to touch existing framework Flexible Reusable Factory Overview Lazy Evaluation State Lazy Evaluation Flexible Reuseable Extendible Desing first, then implementation. Don’t jump to implementations in the middle to check what’s available & modify my design based on it  identify the right thing first! Then figure out the optimal & realistic way to do it Show how prime number works on Wednesday Decorator Union Extendible …

Example Create a lazy list of monotonically Incremented integers: Cons Overhead – initialization and transition