Centralized vs decentralized
Download
1 / 41

Centralized vs. Decentralized - PowerPoint PPT Presentation


  • 112 Views
  • Updated 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)


Centralized vs decentralized

  • 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.


    Centralized vs decentralized


    Centralized vs decentralized

    • MatchVisitor>>visitAlternation: aNode

    • | initialState finalState |

    • initialState := state.

    • finalState := REState new.

    • components do: [ :eachComponent |

    • state := initialState.

    • eachComponent accept: self.

    • finalState addAll: state]

    • state := finalState


    Centralized vs decentralized

    • 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.


    Centralized vs decentralized


    Summary
    Summary

    • Two related patterns:

    • Interpreter - distribute code over class hierarchy

    • Visitor - centralize code in single class