More Design Patterns In Delphi

1
More Design Patterns In Delphi
Session Code D3.03 Track Delphi

• Jim Cooper
• Falafel Software

2
Topics

• Discuss some lesser known patterns from the GoF
• Examine example code for an application
• Somewhat contrived, but we only have an hour
• Assume some knowledge of patterns
• Most important point is that a pattern is not a
  code template

3
Example

• A necessarily small piece of software
• Read and display CSV files
• Read and display XML files
• Will automatically detect the type of file being
  read, and parse it appropriately
• Used refactorings on this code. An example is in
  the Refactorings paper

4
Parsing CSV files

• Comma delimited text
• Stuff,123,More, with comma,,Last
• Often would use a state machine
• Models a set of states
• From each state, particular inputs cause
  transitions to other states

5
Finite State Machine

• This example is from ToD, with the kind
  permission of Julian Bucknall

6
State Pattern

• Allow an object to alter its behaviour when its
  internal state changes. The object will appear to
  change its class
• Cannot actually change class, so we mimic that
• Participants are context (interface to external
  systems) and states.

7
State Pattern - Code

• Context is TCsvParser
• All states derive from TCsvParserState one for
  each state in the FSM
• Note caching of state objects
• Sometimes need to create and destroy states on
  the fly
• State objects often need access to the context

8
Parsing XML Files

• Wont attempt a full-blown parser!
• Only allow a subset of XML, but we still have a
  small language
• Use a recursive descent compiler
• See the Dragon Book for details
• Output is an abstract syntax tree, where each
  node represents an element of the language

9
Grammar

• XmlDoc -gt Prolog0..1 TagList0..1
• Prolog -gt lt?xml PrologData?gt
• TagList -gt Node
• Node -gt StartTag Data TagList EndTag
• StartTag -gt ltTagNamegt
• EndTag -gt lt/TagNamegt
• PrologData -gt Any printable chars except lt,gt,/
  and ?
• Data -gt Any printable chars except lt,gt and
  /
• TagName -gt Any printable chars except
  lt,gt,/,space,?
• Ignore DTDs, attributes, escaped characters
• (e.g. lt), structure of prolog data and empty
• element tags

10
Example XML file

• We will be able to parse things like this
• lt?xml version"1.0"?gt
• ltListgt
• ltSomeStuffgtStuff 1 is herelt/SomeStuffgt
• ltSomeStuffgtStuff 2 is herelt/SomeStuffgt
• ltSomeStuffgtStuff 3 is herelt/SomeStuffgt
• ltSomeStuffgtStuff 4 is herelt/SomeStuffgt
• lt/Listgt

11
Interpreter Pattern

• Given a language, define a representation for
  its grammar along with an interpreter that uses
  the representation to interpret sentences in the
  grammar
• Definition of interpret is broad, and includes
  other things than executing instructions

12
Interpreter Pattern - 2

• We will be defining a class for each element in
  the grammar, so this pattern works best if the
  grammar is not too complex
• Can be inefficient way to represent data
• Recursive descent compilers have similar
  limitations and are a good match for feeding the
  interpreter

13
Interpreter Pattern - Code

• Requires client to build syntax tree
• Base class of tree is the abstract expression
  class
• Has abstract method to perform interpret
  operation Search and Replace in our case
• Will allow operation on just Data or Tags as
  well, so need to understand document structure

14
Interpreter Pattern Code 2

• Subclass for each grammar element
• Terminal expressions (refactored out)
• PrologData, Data, TagName
• Actually do search and replace on these elements
• Nonterminal expressions
• Made up of other expressions
• Call SearchAndReplace on those other expressions

15
Visitor Pattern

• Represent an operation to be performed on the
  elements of an object structure. Visitor lets you
  define a new operation without changing the
  classes of the elements on which it operates.
• Moves operations from tree nodes to another class

16
Visitor Pattern - Code

• Declare a Visitor class, which has a Visit method
  for each node type in the object structure
• Can use method overloading in Delphi
• Methods virtual so visitor descendants can choose
  which to implement
• Accept method in base expression class note
  similarity with SR

17
Visitor Pattern - 2

• Implementing new visitors requires a new visitor
  class, but no changes to the syntax tree
• Similar operations are grouped together
• Can break encapsulation by needing to know too
  much about nodes
• Changing the object structure will break visitor
  classes

18
Documents

• Store some information about the document we are
  looking at
• Used as a context in many patterns
• Uses a stringlist to hold the text

19
Strategy Pattern

• Define a family of algorithms, encapsulate each
  one, and make them interchangeable. Strategy lets
  the algorithm vary independently from clients
  that use it.
• This pattern is a way to use different techniques
  for the same operation

20
Strategy Pattern - Code

• Hide details of SR and pretty printing from
  users of document
• In our case, have 2 operations per strategy, and
  one strategy per file type
• Base class is abstract to force implementation in
  descendants
• Note access to context (Document)

21
Strategy Pattern - 2

• Could subclass context to have 2 document classes
• Mixes algorithms with document
• Can be difficult to structure hierarchy,
  especially if several operations
• More objects in system
• Strategy and context can be closely coupled
• Can have default algorithms

22
Command Pattern

• Encapsulate a request as an object, thereby
  letting you parameterise clients with different
  requests, queue or log requests, and support
  undoable operations.
• Want to be able to undo operations
• Delphi actions are an example of the Command
  pattern

23
Command Pattern - Code

• Abstract base command class
• Execute and Rollback methods
• Use Template pattern
• Descendant class for each command
• Need a reference to the document (the receiver)
• Not always needed
• Separates out command logic

24
Memento Pattern

• Without violating encapsulation, capture and
  externalise an objects internal state so that
  the object can be restored to this state later.
• Stores an objects state
• We will use it to support undo operations

25
Memento Pattern - 2

• Normally need 3 types of object
• Memento stores state information
• Caretaker stores the memento(s)
• Originator creates mementos, and uses them to
  go back to earlier state
• Memento class needs a lot of info about the
  originators
• To avoid encapsulation problems declare both in
  the same unit

26
Memento Pattern - Code

• Document class is our originator
• Memento is simple, just stores document text -
  usually more complex
• Memento property accessors get and set document
  state
• Use memento in pretty printing command/rollback
• Need a list of commands, so...

27
Facade Pattern

• Provide a unified interface to a set of
  interfaces in a subsystem. Facade defines a
  higher-level interface that makes the subsystem
  easier to use.
• Hides a complex subsystem behind a simple
  interface
• Particularly good if subsystem has many tightly
  coupled classes

28
Facade Pattern - 2

• Reduces coupling between elements of the
  subsystem and clients
• Can change subsystem without affecting clients
• Subsystem objects should not normally know about
  the facade

29
Facade Pattern - Code

• We have a facade to hide the commands and the
  undo/redo list
• Also hides document from the UI
• UI code is now one line of code per menu item
• Facade is normally a Singleton

30
References

• Design Patterns. Elements of Reusable
  Object-Oriented Software
• Gamma, Helm, Johnson, Vlissides
• Some find this too abstract

31
Questions?
32
Thank you
You can contact me further at jim_at_falafelsoft.com
33
Evaluatieformulier
Vul je evaluatieformulier in en maak kans op
waanzinnige prijzen!! Session Code D3.03