GoF: 2.1-2.6 Document Editor Example Rebecca Miller-Webster.

Slides:



Advertisements
Similar presentations
Matt Klein. Decorator Pattern  Intent  Attach Additional responsibilities to an object by dynamically. Decorators provide a flexible alternative to.
Advertisements

1 Structural Design Patterns - Neeraj Ray. 2 Structural Patterns - Overview n Adapter n Bridge n Composite n Decorator.
[Course Title] [Module Title]
GoF Sections 2.7 – 2.9 More Fun with Lexi. Lexi Document Editor Lexi tasks discussed:  Document structure  Formatting  Embellishing the user interface.
Design Patterns Copyright © Vyacheslav Mukhortov, Nikita Nyanchuk-Tatarskiy, Copyright © INTEKS LLC,
C15: Design Patterns Gamma,Helm,Johnson,Vlissides (GOF)
Plab – Tirgul 12 Design Patterns
GoF: Document Editor Example
Design Patterns CS is not simply about programming
Design Patterns David Talby. This Lecture n Patterns for a User Interface u Representing a Document F Composite, Flyweight, Decorator u Writing Portable.
GoF: Document Editor Example A Case Study.
Design Patterns. CS351 - Software Engineering (AY2007)Slide 2 Behavioral patterns Suppose we have an aggregate data structure and we wish to access the.
Basic Design Patterns 2. Designing a Document Editor Gabriel Mañana Ed. 453 Of. 120 Ext unal.edu.co.
Design Patterns Based on Design Patterns. Elements of Reusable Object-Oriented Software. by E.Gamma, R. Helm, R. Johnson,J. Vlissides.
The Composite Pattern.. Composite Pattern Intent –Compose objects into tree structures to represent part-whole hierarchies. –Composite lets clients treat.
Design patterns Observer,Strategi, Composite,Template (Chap 5, 6)
Design Patterns Module Name - Object Oriented Modeling By Archana Munnangi S R Kumar Utkarsh Batwal ( ) ( ) ( )
GoF Sections 2.7 – 2.9 More Fun with Lexi. Lexi Document Editor Lexi tasks discussed:  Document structure  Formatting  Embellishing the user interface.
Copyright © Active Frameworks Inc. - All Rights Reserved - V2.0Document Editor - Page L2-5 PS95&96-MEF-L9-5 Dr. M.E. Fayad  Document Structure.
Lecture 4: More UML Diagrams, Patterns MISM/MSIT Fall 2001.
Katie C. O’Shea Dennis T. Tillman 11 February 2K2 Flyweight.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns VI Composite, Iterator, and Visitor Patterns.
Design Patterns academy.zariba.com 1. Lecture Content 1.What are Design Patterns? 2.Creational 3.Structural 4.Behavioral 5.Architectural 6.Design Patterns.
© 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Design Patterns Case Study: Designing.
More OOP Design Patterns
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
Creational Patterns Making Objects The Smart Way Brent Ramerth Abstract Factory, Builder.
MVC pattern and implementation in java
BDP Behavioral Pattern. BDP-2 Behavioral Patters Concerned with algorithms & assignment of responsibilities Patterns of Communication between Objects.
Design Patterns.
Design Patterns and Graphical User Interfaces Horstmann ,
Prof. Aiken CS 169 Lecture 51 Design Patterns CS169 Lecture 5.
05 - Patterns Intro.CSC4071 Design Patterns Designing good and reusable OO software is hard. –Mix of specific + general –Impossible to get it right the.
Design a Document Editor Oksana Protsyk Yaroslav Kaplunskiy.
A Case Study: Designing a Document Editor “ Lexi ”
ISP666 MVC & Design Patterns. Outline Review Event Programming Model Model-View-Controller Revisit Simple Calculator Break Design Patterns Exercise.
Patterns in programming 1. What are patterns? “A design pattern is a general, reusable solution to a commonly occurring problem in software. A design.
Lexi case study (Part 2) Presentation by Matt Deckard.
18 April 2005CSci 210 Spring Design Patterns 1 CSci 210.
CSE 403 Lecture 14 Design Patterns. Today’s educational objective Understand the basics of design patterns Be able to distinguish them from design approaches.
Design Patterns CS 124 Reference: Gamma et al (“Gang-of-4”), Design Patterns.
Structural Design Patterns
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns V More Structural Patterns.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns VIII Chain of Responsibility, Strategy, State.
08 - StructuralCSC4071 Structural Patterns concerned with how classes and objects are composed to form larger structures –Adapter interface converter Bridge.
Structural Patterns1 Nour El Kadri SEG 3202 Software Design and Architecture Notes based on U of T Design Patterns class.
Linzhang Wang Dept. of Computer Sci&Tech, Nanjing University The Strategy Pattern.
DESIGN PATTERNS COMMONLY USED PATTERNS What is a design pattern ? Defining certain rules to tackle a particular kind of problem in software development.
The Strategy Pattern (Behavioral) ©SoftMoore ConsultingSlide 1.
Example to motivate discussion We have two lists (of menu items) one implemented using ArrayList and another using Arrays. How does one work with these.
CS 5150 Software Engineering Lecture 16 Program Design 3.
Design Patterns Creational Patterns. Abstract the instantiation process Help make the system independent of how its objects are created, composed and.
COMPOSITE PATTERN NOTES. The Composite pattern l Intent Compose objects into tree structures to represent whole-part hierarchies. Composite lets clients.
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
Strategy Pattern Jim Fawcett CSE776 – Design Patterns Fall 2014.
Chapter 10 Design Patterns.
Common Design Patterns
Linzhang Wang Dept. of Computer Sci&Tech, Nanjing University
Introduction to Design Patterns
Case Study 1: Designing a Document Editor
Software Design and Architecture
Chapter-II A Case Study:
object oriented Principles of software design
Design Patterns - A few examples
Design Patterns A Case Study: Designing a Document Editor
A Case Study: Designing a Document Editor
Strategy Design Pattern
Creational Patterns.
Strategy Pattern Jim Fawcett CSE776 – Design Patterns Fall 2014.
Presentation transcript:

GoF: Document Editor Example Rebecca Miller-Webster

Document Editor What are your first thoughts about how to build a document editor? –Internal structure –Formatting –Gui –Spell Check

Design Problems Document Structure –Internal structure; need to traverse Formatting –Arrange text into lines & columns –Which objects carry out formatting –How interact with internal representation

Design Problems Embellishing the user interface –Scroll bars, borders etc –Independent of the rest of the application Support multiple look-and-feel Support multiple window systems

Design Problems For Next Time: User Operations –Buttons, pull-down menus Spelling checking and hyphenation

Document Structure Arrangement of graphical elements Users need to treat collection and single elements the same (line vs. table) –Composite Pattern! Internal Representation –Maintain physical structure, present visually, map display and physical structures

Document Structure Use recursive composition Glyphs: abstract class –Primitive graphical elements –Structural elements –Responsibilities: Draw themselves Where they are Children and parent

Document Structure Are there any problems with these Glyphs? -Strict hierarchy -Object for every character (efficiency) -Could share Glyphs -Flyweight Pattern: share objects between different contexts; operation takes extrinsic state; objects represent internal state

Formatting Know how to represent physical structure Need to construct particular structure Formatting: breaking collection of glyphs into lines Trade-offs: quality, speed, space

Formatting Encapsulate Format algorithm –Compositor: formatting algorithm What glyphs to format and when to do formatting –Composition: special glyph class Gets Compositor (specific algorithm) when created and tells compositor to compose its glyphs Compositor-Composition ensures separation between physical representation and formatting Strategy Pattern –Objects encapsulate algorithms and the context in which they operate –Must design interface to support range of algorithms

Embellishing the User Interface Border and Scrollbar Easily add and remove –No inheritance (run-time, lots of classes) –Object composition (embellishment is object) Border contain Glyph? Glyph contain Border? (modify glyph class to be aware of border)

Embellishing the User Interface Transparent enclosure –1) single child/component composition –2) compatible interfaces MonoGlyph (subclass of glyph) –Stores reference to a component (glyph) and forwards requests to it –Performs embellishment before or after sending glyph the request (draw itself)

Embellishing the User Interface Decorator Pattern –Attach additional responsibilities to object dynamically –Enclose component in another component –Nest decorators recursively –Forwards requests to component –Can perform additional actions before or after

Supporting Multiple Look-and- Feel Standards Portability Support for current and future 2 sets of classes: –Set of abstract glyph subclass for each widget category –Set of concrete subclasses to implement different standards

Supporting Multiple Look-and- Feel Standards Abstract Object Creation with Factories –One class is responsible for creating objects –Set standard and then all objects are created with that standard Abstract Factory Pattern –Provides interface for creating families of related or dependent objects without specifying concrete classes Singleton –Ensure a class has only on instance –Provide global point of access

Supporting Multiple Windows Systems Abstract Factory? –Unlikely interface for different vendors are compatible thus don’t have common abstract product class –Encapsulate Implementation Dependencies Window Class: general actions –Draw geometric shapes –Iconifiy and de-iconify themselves –Resize self –Redraw contents on demand

Supporting Multiple Windows Systems Intersection or union of functionality? One version of Windows and subclasses for each Windows platform? Implementation specific subclasses of Window class? OR …

Supporting Multiple Windows Systems Encapsulate the concept that varies WindowImp class: abstract class for objects that encapsulate system-dependent code Configure window object with instance of WindowImp Bridge Pattern: –Decouple abstraction from implementation

Take Away You’re not a fortune teller Decoupling/Independence –Internal/external, abstraction/implementation Use patterns appropriately: –Inheritance vs. object composition (user interface) –Abstract Factory vs. Encapsulate Dependencies (Window) Transparency Focus on the concept that varies