1. More Design Patterns In Delphi Jim Cooper Falafel Software Session Code: D3.03 Track: Delphi

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 Won’t 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 -> Prolog 0..1 TagList 0..1 Prolog -> TagList -> Node* Node -> StartTag [Data | TagList] EndTag StartTag -> EndTag -> PrologData -> [Any printable chars except,/ and ? ]* Data -> [Any printable chars except and / ]* TagName -> [Any printable chars except,/,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: Stuff 1 is here Stuff 2 is here Stuff 3 is here Stuff 4 is here

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 S&R

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 S&R 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 object’s internal state so that the object can be restored to this state later.” Stores an object’s 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. You can contact me further at jim@falafelsoft.com Thank you

33. 33 Evaluatieformulier Vul je evaluatieformulier in en maak kans op waanzinnige prijzen!! Session Code: D3.03