Design Pattern
- 1. Design Pattern “A case study: Designing a document editor” Dr. Himanshu Hora SRMS College of Engineering & Technology Bareilly (UP) INDIA 1
- 2. Contents • Introduction to Lexi features • Design problems • Spelling Checking & Hyphenation • Solution: Encapsulate Traversal • Conclusion 2
- 3. Introduction to Lexi Features • WYSIWYG Document Editor • Mix text and graphics in a variety of styles • Pull-down Menus • Scrollbars • Icons for jumping to a particular page 3
- 4. 4
- 5. Design Problems 1. Document Structure 2. Formatting 3. Embellishing the user interface 4. Supporting multiple look-and-feel standards 5. Supporting multiple window systems 6. User Operations 5
- 6. Document Structure • Goals: –present document’s visual aspects –drawing, hit detection, alignment –support physical structure (e.g., lines, columns) • Constraints/forces: –treat text & graphics uniformly –no distinction between one & many 6
- 7. • Some constraints: – we should treat text and graphics uniformly – our implementation shouldn’t have to distinguish between single elements and groups of elements in the internal representation • Recursive Composition: – a common way to represent hierarchically structured information 7
- 8. 8
- 9. • Glyphs: – an abstract class for all objects that can appear in a document structure – three basic responsibilities, they know • how to draw themselves, what space they occupy, and their children and parent • Composite Pattern: – captures the essence of recursive composition in object-oriented terms 9
- 10. 10
- 11. 11
- 12. Formatting • A structure that corresponds to a properly formatted document • Representation and formatting are distinct – the ability to capture the document’s physical structure doesn’t tell us how to arrive at a particular structure • “Formatting” mean breaking a collection of glyphs in to lines • Encapsulating the formatting algorithm – keep formatting algorithms completely independent of the document structure – make it is easy to change the formatting algorithm – We’ll define a separate class hierarchy for objects that encapsulate formatting algorithm 12
- 13. • Compositor and Composition: – We’ll define a Compositor class for objects that can encapsulate a formatting algorithm – The glyphs Compositor formats are the children of a special Glyph subclass called Composition – When the composition needs formatting, it calls its compositor’s Compose operation – Each Compositor subclass can implement a different line breaking algorithm • 13
- 14. 14
- 15. 15
- 16. Embellishing the User Interface • Considering adds a border around the text editing area and scrollbars that let the user view the different parts of the page here • Transparent Enclosure – object composition • Border and Scroller should be a subclass of Glyph – two notions • single-child (single-component) composition • compatible interfaces 16
- 17. • Monoglyph: – We can apply the concept of transparent enclosure to all glyphs that embellish other glyphs – the class, Monoglyph • Decorator Pattern: – captures class and object relationships that support embellishment by transparent enclosure 17
- 18. 18
- 19. Supporting Multiple Look-and-Feel Standards • Design to support the look-and-feel changing at run-time • Abstracting Object Creation: – widgets – two sets of widget glyph classes for this purpose – Lexi needs a way to determine the look-and-feel standard being targeted – We must avoid making explicit constructor calls – We must also be able to replace an entire widget set easily – We can achieve both by abstracting the process of object creation 19
- 20. • Factories and Product Classes – Factories create product objects – The example • Abstract Factory Pattern – capture how to create families of related product objects without instantiating classes directly 20
- 21. 21
- 22. 22
- 23. Supporting Multiple Window Systems • Lexi to run on many existing window systems having different programming interfaces • Encapsulating Implementation Dependencies – The Window class interface encapsulates the things windows tend to do across window systems – The Window class is an abstract class • Window and WindowImp • Bridge Pattern – to allow separate class hierarchies to work together even as they evolve independently 23
- 24. 24
- 25. 25
- 26. 26
- 27. User Operations • Requirements: – Lexi provides different user interfaces for the operations it supported – These operations are implemented in many different classes – Lexi supports undo and redo • The challenge is to come up with a simple and extensible mechanism that satisfies all of these needs • Encapsulating a Request: – We could parameterize MenuItem with a function to call, but that’s not a complete solution – We should parameterize MenuItems with an object, not a function 27
- 28. • Command Class and Subclasses: – The Command abstract class consists of a single abstract operation called “Execute” – MenuItem can store a Command object that encapsulates a request – When a user choose a particular menu item, the MenuItem simply calls Execute on its Command object to carry out the request 28
- 29. 29
- 30. 30
- 31. • Undoability: – To undo and redo commands, we add an Unexecute operation to Command’s interface – A concrete Command would store the state of the Command for Unexecute – Reversible operation returns a Boolean value to determine if a command is undoable • Command History: – a list of commands that have been executed present past commands 31
- 32. Spelling Checking & Hyphenation • Goals: – analyze text for spelling errors – introduce potential hyphenation sites • Constraints/forces: – support multiple algorithms – don’t tightly couple algorithms with document structure 32
- 33. Solution: Encapsulate Traversal • Iterator – encapsulates a traversal algorithm without exposing representation details to callers – uses Glyph’s child enumeration operation – This is an example of a “preorder iterator” • Intent – access elements of a container without exposing its representation • Applicability – require multiple traversal algorithms over a container – require a uniform traversal interface over different containers – when container classes & traversal algorithm must vary independently 33
- 34. Structure 34
- 35. • Consequences: +flexibility: aggregate & traversal are independent +multiple iterators & multiple traversal algorithms – additional communication overhead between iterator & aggregate • Implementation: – internal versus external iterators – violating the object structure’s encapsulation – robust iterators – synchronization overhead in multi-threaded programs – batching in distributed & concurrent programs • Known Uses: – C++ STL iterators – JDK Enumeration, Iterator – Unidraw Iterator 35
- 36. Conclusion • design reuse • uniform design vocabulary • understanding, restructuring, & team communication • provides the basis for automation • a “new” way to think about design 36
- 37. 37 Dr. Himanshu Hora SRMS College of Engineering & Technology Bareilly (UP) INDIA