【免费】设计模式——可复用的OO软件资源-CSDN文库

共1112个文件

htm：583个

gif：514个

idx：10个

ajax

asp.net

java

vb.net

需积分: 0 113 浏览量 2007-10-20 12:56:46 上传评论收藏 4.22MB ZIP 举报

资源详情

资源评论

资源推荐

收起资源包目录

设计模式——可复用的OO软件（1112个子文件）

cdsearch.cab 44KB

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

overview.gif 18KB

fontc047.gif 17KB

overview.gif 16KB

bigmap.gif 16KB

window.gif 13KB

facto056.gif 13KB

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

compo075.gif 7KB

produ020.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

chapba5b.gif 6KB

compo070.gif 6KB

共 1112 条

<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> This chapter presents a case study in the design of a "What-You-See-Is-What-You-Get" (or "WYSIWYG") document editor called Lexi.<A NAME="fn1"></A><A HREF="#footnote1">1</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. <A NAME="lexi-userint"></A> <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. <A NAME="editor_Lexi"></A> <IMG SRC="Pictures/doc.gif"> Figure 2.1:  Lexi's user interface <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> We will examine seven problems in Lexi's design: <OL> <A NAME="auto1001"></A> <LI>Document structure. 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> <A NAME="auto1003"></A> <LI>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?</LI> <A NAME="auto1004"></A> <A NAME="auto1005"></A> <LI>Embellishing the user interface. 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> <A NAME="lexi-looknfeel"></A> <A NAME="present-manage"></A> <LI>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.</LI> <A NAME="auto1007"></A> <A NAME="multiple-windows"></A> <LI>Supporting multiple window systems. 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> <A NAME="auto1009"></A> <LI>User operations. 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> <A NAME="auto1011"></A> <LI>Spelling checking and hyphenation. 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> 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. <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> 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 structurelines, columns, figures, tables, and other substructures.<A NAME="fn2"></A><A HREF="#footnote2">2</A> In turn, these substructures have substructures of their own, and so on. <A NAME="auto1013"></A> 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. <A NAME="auto1014"></A> In particular, the internal representation should support the following: <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> <A NAME="auto1017"></A> <LI>Generating and presenting the document visually.</LI> <A NAME="auto1018"></A> <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> 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. <A NAME="auto1021"></A> 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. <A NAME="auto1022"></A> 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 pote