centralized vs decentralized
Download
Skip this Video
Download Presentation
Centralized vs. Decentralized

Loading in 2 Seconds...

play fullscreen
1 / 41

Centralized vs. Decentralized - PowerPoint PPT Presentation


  • 112 Views
  • Uploaded on

Centralized vs. Decentralized. Interpreter Pattern Visitor Pattern. Defining a picture. Drawing. CompFig. CompFig. TextFig. TextFig. RectangleFig. RectangleFig. Defining a Language for Pictures. Figure - displayOn: is abstract method CompositeFigure Drawing RectangleFigure

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Centralized vs. Decentralized' - kele


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
centralized vs decentralized

Centralized vs. Decentralized

Interpreter Pattern

Visitor Pattern

defining a picture
Defining a picture

Drawing

CompFig.

CompFig.

TextFig.

TextFig.

RectangleFig.

RectangleFig.

defining a language for pictures
Defining a Language for Pictures
  • Figure - displayOn: is abstract method
  • CompositeFigure
  • Drawing
  • RectangleFigure
  • TextFigure
interpreter pattern
Interpreter Pattern
  • Tree of objects is a kind of program
  • Interpret program by sending message to root, which is recursively sent to entire tree.
  • Not about parsing!!!
object oriented interpreters
Object-Oriented Interpreters
  • To write a little object-oriented interpreter for a language L:
    • 1) make a subclass of LParseNode for each rule in the grammar of L
    • 2) for each subclass, define an interpreter method that takes the current context as an argument.
object oriented interpreters1
Object-Oriented Interpreters
  • 3) define protocol for making a tree of LParseNodes.
  • 4) define a program for L by building an abstract syntax tree.
example valuemodels
Example: ValueModels

arguments

ValueModel

value

BlockValue

ValueHolder

block

value

value

value

valuemodels
ValueModels

BlockValue

  • | x y |
  • x := 3 asValue.
  • y := 7 asValue.
  • x + y
  • ValueModel>> + aValue
  • ^ BlockValue
  • block: [:a :b | a value * b value]
  • arguments: (Array with: self with: aValue asValue)

ValueHolder

ValueHolder

example regular expression checker
Example: Regular Expression Checker
  • Grammar: exp ::= string | exp ‘+’ exp | exp ‘&’ exp | exp ‘repeat’
  • Step 1: define RegExpNode, MatchRENode, AlternationRENode, SequenceRENode, RepeatRENode
  • Step 2: define a match: method for each class that takes an input state as an argument
regular expression classes
Regular Expression Classes

RegExpNode

Match

MatchRENode

RepeatRENode

contents

Match

Match

AlternationRENode

SequenceRENode

Match

Match

regular expression objects
Regular Expression Objects

\'this is a \' (\'very \' *) (\'big ’ + \'small \') (\'dog\' + \'cat\' + \'mouse\')

SequenceRENode

AlternationRENode

MatchRENode

\'this is a \'

AlternationRENode

RepeatRENode

MatchRENode

\'cat\'

MatchRENode

\'small \'

MatchRENode

\'very \'

MatchRENode

\'big \'

MatchRENode

\'dog\'

MatchRENode

\'mouse

this is a very very very big mouse

matching
Matching
  • SequenceRENode>>match: inputState
  • ^components
  • inject: inputState
  • into: [:nextState :exp |
  • exp match: nextState]
matching1
Matching
  • RepeatRENode>>match: inputState
  • | aState finalState |
  • aState := inputState.
  • finalState := inputState copy.
  • ...
continued
(continued)
  • [aState notEmpty]
  • whileTrue:
  • [aState := component match: aState.
  • finalState addAll: aState].
  • ^finalState
matching2
Matching
  • AlternationRENode>>match: inputState
  • | finalState |
  • finalState := REState new.
  • components do: [ :exp | finalState addAll: (exp match: inputState)]
  • ^finalState
matching3
Matching
  • MatchRENode>>match: inputState
  • | finalState tStream |
  • finalState := REState new.
  • ...
  • REState is a collection of streams.
continued1
(continued)
  • inputState
  • do: [:stream |
  • tStream := stream copy.
  • (tStream nextAvailable:
  • components size) = components
  • ifTrue: [finalState add: tStream]].
  • ^finalState
protocol for building tree
Protocol for Building Tree
  • Define ”+" and "repeat" and ”&" as methods on RegExpNodes and any literals that are to be treated as patterns, such as strings.
  • Then ((\'dog \' + \'cat \') repeat & \'weather\') matches: \'dog dog cat weather\' is true.
interface method
Interface method
  • RegExpNode>>matches: anArg
  • | inputState |
  • inputState := (streamOrCollection isKindOf: Collection)
  • ifTrue: [REState with: (ReadStream on: streamOrCollection)]
  • ifFalse: [REState with: streamOrCollection].
  • (self match: inputState) do: [:stream | stream atEnd ifTrue: [^true]].
  • ^false
interface methods
Interface methods
  • Define +, &, repeat, and asRENode in RegExpNode and String
  • + anArg
  • ^AlternationRENode new
  • components: (Array with: self with: anArg asRENode)
slide21
Other examples of Interpreter pattern:
    • • producing Postscript for a document
    • • figuring out the value of an insurance policy
    • • spreadsheet
    • • compiling a program
  • C program would use case statement
replacing cases with subclasses
Replacing Cases with Subclasses
  • Advantages
    • • instead of modifying case statements, add a new subclass
    • • easier to parameterize
    • • can use inheritance to make new options
replacing cases with subclasses1
Replacing Cases with Subclasses
  • Disadvantages
    • • program is spread out,
      • + harder to understand
      • + harder to replace algorithm
    • • state of object can change, but class can not
how to centralize algorithms
How To Centralize Algorithms
  • Define isAlternative, isRepeat, isSequence, isMatch, childrenDo:
  • fix: anRENode
  • anRENode isMatch
  • ifTrue: [anRENode contents: (anRENode contents capitalize)]
  • ifFalse: [anRENode childrenDo: [:child | self fix: child]]
when to centralize algorithm
When to Centralize Algorithm
  • Use centralized algorithm when you need to
    • • change entire algorithm at once
    • • look at entire algorithm at once
    • • change algorithm, but not add new classes of components
visitor pattern
Visitor pattern
  • Visitor lets you centralize algorithm, lets you create a family of algorithms by inheritance, and makes it easy to create new algorithms.
  • Major problem is that adding a new kind of parse node requires adding a new method to each visitor.
visitor pattern1
Visitor pattern
    • • two kinds of classes: nodes and node visitor
    • • nodes have accept: method with visitor as an argument
    • • accept: method sends visit message
  • SequenceRENode>>accept: aVisitor
    • aVisitor visitSequence: self
visitor pattern2
Visitor pattern
  • • each node class sends a different visit message to visitor
  • visitSequence:, visitAlternation:, visitRepetition:, visitMatch:
  • • visitor defines a visit method for each class of parse tree node
  • • uses double dispatching
revisitor and matchvisitor
REVisitor and MatchVisitor
  • An REVisitor implements visitSequence:, visitAlternation:, visitRepetition:, visitMatch:
  • MatchVisitor is an REVisitor with one instance variable, state, and methods to access it.
slide30
MatchVisitor>>visitSequence: sequence
  • ^state := sequence components
  • inject: state
  • into: [:nextState :exp |
  • visitor := MatchVisitor with: nextState.
  • exp match: visitor.
  • visitor state]
slide31
MatchVisitor>>visitAlternation: aNode
  • | initialState finalState |
  • initialState := state.
  • finalState := REState new.
  • components do: [ :eachComponent |
  • state := initialState.
  • eachComponent accept: self.
  • finalState addAll: state]
  • state := finalState
slide32
MatchVisitor>>visitRepeat: aNode
  • | finalState |
  • finalState := state copy.
  • [state notEmpty]
  • whileTrue:
  • [component accept: self.
  • finalState addAll: state].
  • ^finalState
fixvisitor
FixVisitor
  • FixVisitor>>visitMatch: aMatch
  • aMatch contents: (aMatch contents capitalize)
  • FixVisitor>>visitSequence: aSequence
  • aSequence
  • childrenDo: [:child | child accept: self]]
visitor as a refactoring
Visitor as a refactoring
  • Convert an “interpret:” method to Visitor.
  • Precondition: interpret: must not return anything.
  • Create a visitor class V.
  • Find common superclass of the classes that define interpret:, and define
  • interpret: aContext
  • self accept: (V newWith: aContext)
visitor as a refactoring1
Visitor as a refactoring
  • Add an accept: method to every class X with interpret:, and have it send visitX: to argument.
  • Move code for interpret: in class X to visitX: of V. Add accessing methods to X. Change sends of interpret: to accept:
comments
Comments
  • Design pattern is a complex refactoring
  • Visitor illustrates that location of code is arbitrary
visitor pattern3
Visitor Pattern
  • Strengths
    • Can add a new algorithm to operate on a class hierarchy without changing existing classes.
  • Weakness
    • Adding a new node class requires changing visitors.
parsetreeenumerator
ParseTreeEnumerator
  • Smalltalk compiler parse tree hierachy rarely changes.
  • Many programs need to traverse tree:
    • • consistency checkers
    • • program transformation
    • • metrics
  • Keep them out of the parse tree.
visualworks gui specs
VisualWorks GUI Specs
  • A tree of Specs describes the components of a window.
  • You build a window for an application by asking the Spec for that window to do it.
  • UIPolicy is a Visitor that converts a tree of Specs into a tree of VisualComponents.
slide40
dispatchTo: policy with: builder
  • ActionButtonSpec
  • policy actionButton: self into: builder
  • CompositeSpec
  • policy composite: self into: builder
summary
Summary
  • Two related patterns:
  • Interpreter - distribute code over class hierarchy
  • Visitor - centralize code in single class
ad