<HTML>
<HEAD><TITLE>A Case Study: Designing a Document Editor</TITLE>
<SCRIPT>
function setFocus() {
if ((navigator.appName != "Netscape") && (parseFloat(navigator.appVersion) == 2)) {
return;
} else {
self.focus();
}
}
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" onLoad="setFocus()";>
<A NAME="top"></A>
<A NAME="chapter_scenario"></A>
<P>This chapter presents a case study in the design of a
"What-You-See-Is-What-You-Get" (or "WYSIWYG") document editor called
<STRONG>Lexi</STRONG>.<A NAME="fn1"></A><A HREF="#footnote1"><SUP>1</SUP></A> We'll
see how design patterns capture solutions to design problems in
Lexi and applications like it. By the end of this chapter you will
have gained experience with eight patterns, learning them by
example.</P>
<A NAME="lexi-userint"></A>
<P><A HREF="#editor_Lexi">Figure 2.1</A> depicts Lexi's user interface. A
WYSIWYG representation of the document occupies the large rectangular
area in the center. The document can mix text and graphics freely in
a variety of formatting styles. Surrounding the document are the
usual pull-down menus and scroll bars, plus a collection of page icons
for jumping to a particular page in the document.</P>
<A NAME="editor_Lexi"></A>
<P ALIGN=CENTER><IMG SRC="Pictures/doc.gif"><BR><BR>
Figure 2.1: Lexi's user interface</P>
<A NAME="sec2-1"></A>
<H2><A HREF="#sec2-2"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Document Structure"></A>
Design Problems</H2>
<A NAME="auto1000"></A>
<P>We will examine seven problems in Lexi's design:</P>
<OL>
<A NAME="auto1001"></A>
<LI><EM>Document structure.</EM>
The choice of internal representation for the document affects nearly
every aspect of Lexi's design. All editing, formatting, displaying,
and textual analysis will require traversing the representation. The
way we organize this information will impact the design of the rest of
the application.</LI>
<A NAME="auto1002"></A>
<P></P>
<A NAME="auto1003"></A>
<LI><EM>Formatting.</EM>
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?</LI>
<A NAME="auto1004"></A>
<P></P>
<A NAME="auto1005"></A>
<LI><EM>Embellishing the user interface.</EM>
Lexi's user interface includes scroll bars, borders, and drop shadows
that embellish the WYSIWYG document interface. Such embellishments are
likely to change as Lexi's user interface evolves. Hence it's
important to be able to add and remove embellishments easily without
affecting the rest of the application.</LI>
<A NAME="auto1006"></A>
<P></P>
<A NAME="lexi-looknfeel"></A>
<A NAME="present-manage"></A>
<LI><EM>Supporting multiple look-and-feel standards.</EM>
Lexi should adapt easily to different look-and-feel standards
such as Motif and Presentation Manager (PM) without major modification.</LI>
<A NAME="auto1007"></A>
<P></P>
<A NAME="multiple-windows"></A>
<LI><EM>Supporting multiple window systems.</EM>
Different look-and-feel standards are usually implemented on different
window systems. Lexi's design should be as independent of the window
system as possible.</LI>
<A NAME="auto1008"></A>
<P></P>
<A NAME="auto1009"></A>
<LI><EM>User operations.</EM>
Users control Lexi through various user interfaces, including
buttons and pull-down menus. The functionality behind these
interfaces is scattered throughout the objects in the application.
The challenge here is to provide a uniform mechanism both for
accessing this scattered functionality and for undoing its effects.</LI>
<A NAME="auto1010"></A>
<P></P>
<A NAME="auto1011"></A>
<LI><EM>Spelling checking and hyphenation.</EM>
How does Lexi support analytical operations such as 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?</LI>
</OL>
<A NAME="auto1012"></A>
<P>We discuss these design problems in the sections that follow. Each
problem has an associated set of goals plus constraints on how we
achieve those goals. We explain the goals and constraints in detail
before proposing a specific solution. The problem and its solution
will illustrate one or more design patterns. The discussion for each
problem will culminate in a brief introduction to the relevant
patterns.</P>
<A NAME="sec2-2"></A>
<H2><A HREF="#sec2-3"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Formatting"></A>
Document Structure</H2>
<A NAME="editor_sec_document_structure"></A>
<P>A document is ultimately just an arrangement of basic graphical
elements such as characters, lines, polygons, and other shapes. These
elements capture the total information content of the document. Yet an
author often views these elements not in graphical terms but in terms
of the document's physical structure—lines, columns, figures,
tables, and other substructures.<A NAME="fn2"></A><A HREF="#footnote2"><SUP>2</SUP></A>
In turn, these substructures have substructures of their
own, and so on.</P>
<A NAME="auto1013"></A>
<P>Lexi's user interface should let users manipulate these
substructures directly. For example, a user should be able to treat a
diagram as a unit rather than as a collection of individual graphical
primitives. The user should be able to refer to a table as a whole,
not as an unstructured mass of text and graphics. That helps make the
interface simple and intuitive. To give Lexi's implementation
similar qualities, we'll choose an internal representation that
matches the document's physical structure.</P>
<A NAME="auto1014"></A>
<P>In particular, the internal representation should support the
following:</P>
<UL>
<A NAME="auto1015"></A>
<LI>Maintaining the document's physical structure, that is, the
arrangement of text and graphics into lines, columns, tables, etc.</LI>
<A NAME="auto1016"></A>
<P></P>
<A NAME="auto1017"></A>
<LI>Generating and presenting the document visually.</LI>
<A NAME="auto1018"></A>
<P></P>
<A NAME="auto1019"></A>
<LI>Mapping positions on the display to elements in the internal
representation. This lets Lexi determine what the user is
referring to when he points to something in the visual representation.</LI>
</UL>
<A NAME="auto1020"></A>
<P>In addition to these goals are some constraints. First, we should
treat text and graphics uniformly. The application's interface lets
the user embed text within graphics freely and vice versa. We should
avoid treating graphics as a special case of text or text as a special
case of graphics; otherwise we'll end up with redundant formatting and
manipulation mechanisms. One set of mechanisms should suffice for
both text and graphics.</P>
<A NAME="auto1021"></A>
<P>Second, our implementation shouldn't have to distinguish between
single elements and groups of elements in the internal representation.
Lexi should be able to treat simple and complex elements
uniformly, thereby allowing arbitrarily complex documents. The tenth
element in line five of column two, for instance, could be a single
character or an intricate diagram with many subelements. As long as we
know this element can draw itself and specify its dimensions, its
complexity has no bearing on how and where it should appear on the
page.</P>
<A NAME="auto1022"></A>
<P>Opposing the second constraint, however, is the need to analyze the
text for such things as spelling errors and potential hyphenation
points. Often we don't care whether the element of a line is a simple
or complex object. But sometimes an analysis depends on the objects
being analyzed. It makes little sense, for example, to check the
spelling of a polygon or to hyphenate it. The internal
representation's design should take this and other potentially
conflicting constraints into account.</P>
<A NAME="recursivecomposition"></A>
<H3>Recursive Composition</H3>
<A NAME="auto1023"></A>
<P>A common way to represent hierarchically structured inform
设计模式教程及笔记
需积分: 4 198 浏览量
2007-11-05
11:57:44
上传
评论
收藏 4.08MB ZIP 举报
设计模式教程及笔记 （1112个子文件） 
cdsearch.cab 44KB cdsearch.cab 44KB
设计模式基础.doc 131KB
build096.gif 39KB strea010.gif 31KB abfac108.gif 29KB visit003.gif 26KB splash.gif 25KB abfac109.gif 23KB splash.gif 20KB btree097.gif 20KB patmap.gif 18KB patmap.gif 18KB overview.gif 18KB fontc047.gif 17KB fontc047.gif 17KB overview.gif 16KB bigmap.gif 16KB bigmap.gif 16KB window.gif 13KB facto056.gif 13KB doc.gif 12KB doc.gif 12KB facto056.gif 12KB glyph046.gif 12KB class088.gif 11KB build096.gif 11KB visitor.gif 11KB mvc.gif 11KB obser025.gif 11KB bridg100.gif 11KB adapt102.gif 10KB class088.gif 10KB itera037.gif 10KB visitor.gif 10KB itera037.gif 10KB decor066.gif 10KB bridg100.gif 9KB facad059.gif 9KB proto019.gif 9KB facad058.gif 9KB flywe050.gif 9KB btree-3.gif 9KB comma076.gif 9KB glyph046.gif 9KB abfac108.gif 9KB window.gif 9KB obser025.gif 9KB facad058.gif 8KB ieanim.gif 8KB proxy-eg.gif 8KB btree-1.gif 8KB flywe050.gif 8KB btree097.gif 8KB obser023.gif 8KB proto019.gif 8KB produ020.gif 8KB bot3f.gif 8KB btree-2.gif 8KB compo071.gif 8KB spell013.gif 8KB observer.gif 8KB facad059.gif 7KB tmeth007.gif 7KB decor064.gif 7KB adapt103.gif 7KB inter043.gif 7KB textcomp.gif 7KB adapt102.gif 7KB compo071.gif 7KB decor067.gif 7KB compo070.gif 7KB strea010.gif 7KB state-eg.gif 7KB flywe052.gif 7KB produ020.gif 7KB compo075.gif 7KB proxy-eg.gif 7KB media034.gif 7KB windo111.gif 7KB fmeth049.gif 7KB abfac109.gif 7KB flywe052.gif 7KB obser023.gif 7KB tmeth007.gif 6KB adapt105.gif 6KB fmeth048.gif 6KB decor066.gif 6KB visit003.gif 6KB flywe053.gif 6KB visit005.gif 6KB inter042.gif 6KB inter043.gif 6KB compo072.gif 6KB media031.gif 6KB state-eg.gif 6KB chapba4b.gif 6KB chapba4b.gif 6KB chapba5b.gif 6KB chapba5b.gif 6KB共 1112 条
- 1
- 2
- 3
- 4
- 5
- 6
- 12
资源评论
