Unit –II A Case Study

Design Problems:
• seven problems in Lexis's design:
 1.Document Structure:

• Document Structure:
The choice of internal representation for the
document affects nearly every aspect of
Lexis's design. All editing , formatting,
displaying, and textual analysis will require
traversing the representation.
 Document Structure:

Document Structure:
• Goals:
–present document’s visual aspects
–drawing, hit detection, alignment
–support physical
structure (e.g., lines,
columns)
 Document Structure:

• Constraints/forces:
–treat text & graphics uniformly.
–no distinction between one & many.
 Document Structure:

• The internal representation for a

document:
–The internal representation should support.
–maintaining the document’s physical structure.
–generating and presenting the document
visually.
–mapping positions on the display to elements
in the internal representations.
 Document Structure:

• 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
• 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
• Their children and parent
 2.Formatting

• Formatting:
How does Lexi actually arrange text and
graphics into lines and columns?
What objects are responsible for carrying out
different formatting policies?
How do these policies interact with the
document’s internal representation?
• 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.
• here, we’ll restrict “formatting” to 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 algorithms.

• 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
• Compositor and Composition (cont):
– The Compositor-Composition class split ensures a strong separation
between code that supports the document’s physical structure and the
code for different formatting algorithms.
• Strategy pattern:
– intent: encapsulating an algorithm in an object.
– Compositors are strategies. A composition is the context for a compositor strategy.
3.Embellishing the user interface
Embellishing the user interface:
• Lexis user interface include scroll bar,
borders and drop shadows that embellish the
WYSIWYG document interface. Such
embellishments are likely to change as Lexis
user interface evolves.
• 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:
– inheritance-based approach will result in some problems.
– Composition, ScollableComposition, BorderedScrollableComposition.
– object composition offers a potentially more workable and flexible extension mechanism.

• Transparent enclosure (cont):

– object composition (cont)
• Border and Scroller should be a subclass of Glyph.
– two notions
• single-child (single-component) composition.
• compatible interfaces.

• 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.
4.Supporting multiple look-and-feel standards

• Supporting multiple look-and-feel

standards:
• Lexi should adapt easily to different look-and-
feel standards such as Motif and Presentation
Manager (PM) without major modification.
 • Design to support the look-and-feel changing at run-time
• Abstracting Object Creation
– widgets
– two sets of widget glyph classes for this purpose
• a set of abstract glyph subclasses for each category of widget glyph (e.g., ScrollBar).
• a set of concrete subclasses for each abstract subclass that implement different look-and-feel standards (e.g.,
MotifScrollBar and PMScrollBar).

• Abstracting Object Creation (cont):

– 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
• Factories and Product Classes:
– Factories create product objects.

• Abstract Factory Pattern:

– capture how to create families of related product objects without instantiating classes directly
5. Supporting multiple window systems:

• Supporting multiple window systems:

• Different look-and-fell standards are usually
implemented on different window system.
Lexi’s design should be independent of the
window system as possible.
 Supporting Multiple Window Systems:

• We’d like Lexi to run on many existing window systems having different programming interfaces.
• Can we use an Abstract Factory?
– As the different programming interfaces on these existing window systems, the Abstract Factory pattern doesn‘t
work.
– We need a uniform set of windowing abstractions that lets us take different window system impelementations and
slide any one of them under a common interface.

• Encapsulating Implementation Dependencies

– The Window class interface encapsulates the things windows tend to do across window systems

– The Window class is an abstract class

– Where does the implementation live?
• Window and WindowImp
• Bridge Pattern
– to allow separate class hierarchies to work together even as they evolve independently
 6.User Operations
• User Operations:
User control Lexi through various interfaces,
including buttons and pull-down menus. The
functionality beyond these interfaces is
scattered throughout the objects in the
application.
 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.
• it doesn’t address the undo/redo problem.
• it’s hard to associate state with a function.
• functions are hard to extent, and it’s hard to reuse part of them.
– We should parameterize MenuItems with an object, not a function.
• 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
• 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.

• Undoing the Last Command:

• To undo a command, unexecute() is called on the command on the front of the list.
• The “present” position is moved past the last command.
Undoing Previous command:
• Redoing the Next Command:
• To redo the command that was just undone, execute() is called on that command.
• The present pointer is moved up past that command.
• The Command Pattern:
• Encapsulate a request as an object
• The Command Patterns lets you
– parameterize clients with different requests
– queue or log requests
– support undoable operations
• Also Known As: Action, Transaction.
 7.Spelling checking and Hyphenation

• Spelling checking and Hyphenation:How

does Lexi support analytical operations checking
for misspelled words and determining hyphenation
points? How can we minimize the number of
classes we have to modify to add a new analytical
operation?
 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.
• 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”.