Centralized vs decentralized
This presentation is the property of its rightful owner.
Sponsored Links
1 / 41

Centralized vs. Decentralized PowerPoint PPT Presentation


  • 75 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Centralized vs. Decentralized

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

    • MatchVisitor>>visitSequence: sequence

    • ^state := sequence components

    • inject: state

    • into: [:nextState :exp |

    • visitor := MatchVisitor with: nextState.

    • exp match: visitor.

    • visitor state]


    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

    • 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


  • Login