📄 ch18.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD><!-- This document was created from RTF source by rtftohtml version 3.0.1 --> <META NAME="GENERATOR" Content="Symantec Visual Page 1.0"> <META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1"> <TITLE>Teach Yourself C++ in 21 Days</TITLE></HEAD><BODY TEXT="#000000" BGCOLOR="#FFFFFF"><H1 ALIGN="CENTER"><A HREF="ch17.htm" tppabs="http://www.mcp.com/814147200/0-672/0-672-31070-8/htm/ch17.htm"><IMG SRC="BLANPREV.GIF" tppabs="http://www.mcp.com/814147200/0-672/0-672-31070-8/buttons/BLANPREV.GIF"WIDTH="37" HEIGHT="37" ALIGN="BOTTOM" BORDER="0"></A><A HREF="tppmsgs/msgs0.htm#1" tppabs="http://www.mcp.com/sams"><IMGSRC="BLANHOME.GIF" tppabs="http://www.mcp.com/814147200/0-672/0-672-31070-8/buttons/BLANHOME.GIF" WIDTH="37" HEIGHT="37" ALIGN="BOTTOM"BORDER="0"></A><A HREF="index.htm" tppabs="http://www.mcp.com/814147200/0-672/0-672-31070-8/index.htm"><IMG SRC="BLANTOC.GIF" tppabs="http://www.mcp.com/814147200/0-672/0-672-31070-8/buttons/BLANTOC.GIF"WIDTH="37" HEIGHT="37" ALIGN="BOTTOM" BORDER="0"></A><A HREF="ch19.htm" tppabs="http://www.mcp.com/814147200/0-672/0-672-31070-8/htm/ch19.htm"><IMG SRC="BLANNEXT.GIF" tppabs="http://www.mcp.com/814147200/0-672/0-672-31070-8/buttons/BLANNEXT.GIF"WIDTH="37" HEIGHT="37" ALIGN="BOTTOM" BORDER="0"></A></H1><H1></H1><UL> <LI><A HREF="#Heading1">Day 18</A> <UL> <LI><A HREF="#Heading2">Object-Oriented Analysis and Design</A> <UL> <LI><A HREF="#Heading3">The Development Cycle</A> <LI><A HREF="#Heading4">Simulating an Alarm System</A> <UL> <LI><A HREF="#Heading5">Preliminary Design</A> <LI><A HREF="#Heading6">What Are the Objects?</A> <LI><A HREF="#Heading7">Other Objects</A> <LI><A HREF="#Heading8">What Are the Classes?</A> <LI><A HREF="#Heading9">How Are Alarms Reported?</A> <LI><A HREF="#Heading10">Event Loops</A> </UL> <LI><A HREF="#Heading11">Listing 18.1. A simple event loop</A><A HREF="#Heading12">.</A> <LI><A HREF="#Heading13">PostMaster</A> <LI><A HREF="#Heading14">Measure Twice, Cut Once</A> <LI><A HREF="#Heading15">Divide and Conquer</A> <LI><A HREF="#Heading16">Message Format</A> <LI><A HREF="#Heading17">Initial Class Design</A> <LI><A HREF="#Heading18">Rooted Hierarchies Versus Non-Rooted Hierarchies</A> <UL> <LI><A HREF="#Heading19">Figure 18.1.</A> </UL> <LI><A HREF="#Heading20">Designing the Interfaces</A> <UL> <LI><A HREF="#Heading21">Building a Prototype</A> <LI><A HREF="#Heading22">The 80/80 Rule</A> </UL> <LI><A HREF="#Heading23">Designing the PostMasterMessage Class</A> <UL> <LI><A HREF="#Heading24">Application Program Interface</A> </UL> <LI><A HREF="#Heading25">Listing 18.2. PostMasterMessages interface</A><A HREF="#Heading26">.</A> <UL> <LI><A HREF="#Heading27">Programming in Large Groups</A> <LI><A HREF="#Heading28">Ongoing Design Considerations</A> </UL> <LI><A HREF="#Heading29">Design Decisions</A> <UL> <LI><A HREF="#Heading30">Decisions, Decisions</A> </UL> <LI><A HREF="#Heading31">Working with Driver Programs</A> <LI><A HREF="#Heading32">Listing 18.3. A driver program for PostMasterMessage</A><A HREF="#Heading33">.</A> <LI><A HREF="#Heading34">Summary</A> <LI><A HREF="#Heading35">Q&A</A> <LI><A HREF="#Heading36">Workshop</A> <UL> <LI><A HREF="#Heading37">Quiz</A> <LI><A HREF="#Heading38">Exercises</A> </UL> </UL> </UL></UL><P><HR SIZE="4"><H2 ALIGN="CENTER"><A NAME="Heading1"></A><FONT COLOR="#000077">Day 18</FONT></H2><H2 ALIGN="CENTER"><A NAME="Heading2"></A><FONT COLOR="#000077">Object-Oriented Analysisand Design</FONT></H2><P>It is easy to become focused on the syntax of C++ and to lose sight of how andwhy you use these techniques to build programs. Today you will learn<UL> <LI>How to analyze problems from an object-oriented perspective. <P> <LI>How to design your program from an object-oriented perspective. <P> <LI>How to design for reusability and extensibility.</UL><H3 ALIGN="CENTER"><A NAME="Heading3"></A><FONT COLOR="#000077">The Development Cycle</FONT></H3><P>Many volumes have been written about the development cycle. Some propose a "waterfall"method, in which designers determine what the program should do; architects determinehow the program will be built, what classes will be used, and so forth; and thenprogrammers implement the design and architecture. By the time the design and architectureis given to the programmer, it is complete; all the programmer needs to do is implementthe required functionality.</P><P>Even if the waterfall method worked, it would probably be a poor method for writinggood programs. As the programmer proceeds, there is a necessary and natural feedbackbetween what has been written so far and what remains to be done. While it is truethat good C++ programs are designed in great detail before a line of code is written,it is not true that that design remains unchanged throughout the cycle.</P><P>The amount of design that must be finished "up front," before programmingbegins, is a function of the size of the program. A highly complex effort, involvingdozens of programmers working for many months, will require a more fully articulatedarchitecture than a quick-and-dirty utility written in one day by a single programmer.</P><P>This chapter will focus on the design of large, complex programs which will beexpanded and enhanced over many years. Many programmers enjoy working at the bleedingedge of technology; they tend to write programs whose complexity pushes at the limitsof their tools and understanding. In many ways, C++ was designed to extend the complexitythat a programmer or team of programmers could manage.</P><P>This chapter will examine a number of design problems from an object-orientedperspective. The goal will be to review the analysis process, and then to understandhow you apply the syntax of C++ to implement these design objectives.<H3 ALIGN="CENTER"><A NAME="Heading4"></A><FONT COLOR="#000077">Simulating an AlarmSystem</FONT></H3><P>A simulation is a computer model of a part of a real-world system. There are manyreasons to build a simulation, but a good design must start with an understandingof what questions you hope the simulation will answer.</P><P>As a starting point, examine this problem: You have been asked to simulate thealarm system for a house. The house is a center hall colonial with four bedrooms,a finished basement, and an under-the-house garage.</P><P>The downstairs has the following windows: three in the kitchen, four in the diningroom, one in the half-bathroom, two each in the living room and the family room,and two small windows next to the door. All four bedrooms are upstairs, each of whichhas two windows except for the master bedroom, which has four. There are two baths,each with one window. Finally, there are four half-windows in the basement, and onewindow in the garage.</P><P>Normal access to the house is through the front door. Additionally, the kitchenhas a sliding glass door, and the garage has two doors for the cars and one doorfor easy access to the basement. There is also a cellar door in the backyard.</P><P>All the windows and doors are alarmed, and there are panic buttons on each phoneand next to the bed. The grounds are alarmed as well, though these are carefullycalibrated so that they are not set off by small animals or birds.</P><P>There is a central alarm system in the basement, which sounds a warning chirpwhen the alarm has been tripped. If the alarm is not disabled within a setable amountof time, the police are called. If a panic button is pushed, the police are calledimmediately.</P><P>The alarm is also wired into the fire and smoke detectors and the sprinkler system,and the alarm system itself is fault tolerant, has its own internal backup powersupply, and is encased in a fireproof box.<H4 ALIGN="CENTER"><A NAME="Heading5"></A><FONT COLOR="#000077">Preliminary Design</FONT></H4><P>You begin by asking, "What questions might this simulation answer?"For example, you might be able to use the simulation to answer the questions, "Howlong might a sensor be broken before anyone notices?" or "Is there a wayto defeat the window alarms without the police being notified?"</P><P>Once you understand the purpose of the simulation you will know what parts ofthe real system the program must model. Once that is well understood, it becomesmuch easier to design the program itself.<H4 ALIGN="CENTER"><A NAME="Heading6"></A><FONT COLOR="#000077">What Are the Objects?</FONT></H4><P>One way to approach this problem is to set aside issues relating to the user interfaceand to focus only on the components of the "problem space." A first approximationof an object-oriented design might be to list the objects that you need to simulate,and then to examine what these objects "know" and "do."</P><DL> <DD><HR><FONT COLOR="#000077"><B>New Term:</B></FONT><B> </B>The <I>problem space</I> is the set of problems and issues your program is trying to solve. The solution space is the set of possible solutions to the problems. <HR></DL><P>For example, clearly you have sensors of various types, a central alarm system,buttons, wires, and telephones. Further thought convinces you that you must alsosimulate rooms, perhaps floors, and possibly groups of people such as owners andpolice.</P><P>The sensors can be divided into motion detectors, trip wires, sound detectors,smoke detectors, and so forth. All of these are types of sensors, though there isno such thing as a sensor per se. This is a good indication that sensor is an abstractdata type (ADT).</P><P>As an ADT, the class sensor would provide the complete interface for all typesof sensors, and each derived type would provide the implementation. Clients of thevarious sensors would use them without regard to which type of sensor they are, andthey would each "do the right thing" based on their real type.</P><P>To create a good ADT, you need to have a complete understanding of what sensorsdo (rather than how they work). For example, are sensors passive devices or are theyactive? Do they wait for some element to heat up, a wire to break, or a piece ofcaulk to melt, or do they probe their environment? Perhaps some sensors have onlya binary state (alarm state or okay), but others have a more analog state (what isthe current temperature?). The interface to the abstract data type should be sufficientlycomplete to handle all the anticipated needs of the myriad derived classes.<H4 ALIGN="CENTER"><A NAME="Heading7"></A><FONT COLOR="#000077">Other Objects</FONT></H4><P>The design continues in this way, teasing out the various other classes that willbe required to meet the specification. For example, if a log is to be kept, probablya timer will be needed; should the timer poll each sensor or should each sensor fileits own report periodically?</P><P>The user is going to need to be able to set up, disarm, and program the system,and so a terminal of some sort will be required. You may want a separate object inyour simulation for the alarm program itself.<H4 ALIGN="CENTER"><A NAME="Heading8"></A><FONT COLOR="#000077">What Are the Classes?</FONT></H4><P>As you solve these problems, you will begin to design your classes. For example,you already have an indication that <TT>HeatSensor</TT> will derive from <TT>Sensor</TT>.If the sensor is to make periodic reports, it may also derive via multiple inheritancefrom <TT>Timer</TT>, or it may have a timer as a member variable.</P><P>The <TT>HeatSensor</TT> will probably have member functions such as <TT>CurrentTemp()</TT>and <TT>SetTempLimit()</TT> and will probably inherit functions such as <TT>SoundAlarm()</TT>from its base class, <TT>Sensor</TT>.</P><P>A frequent issue in object-oriented design is that of encapsulation. You couldimagine a design in which the alarm system has a setting for <TT>MaxTemp</TT>. Thealarm system asks the heat sensor what the current temperature is, compares it tothe maximum temperature, and sounds the alarm if it is too hot. One could argue thatthis violates the principle of encapsulation. Perhaps it would be better if the alarmsystem didn't know or care what the details are of temperature analysis; arguablythat should be in the <TT>HeatSensor</TT>.</P><P>Whether or not you agree with that argument, it is the kind of decision you wantto focus on during the analysis of the problem. To continue this analysis, one couldargue that only the <TT>Sensor</TT> and the <TT>Log</TT> object should know any detailsof how sensor activity is logged; the <TT>Alarm</TT> object shouldn't know or care.</P><P>Good encapsulation is marked by each class having a coherent and complete setof responsibilities, and no other class having the same responsibilities. If thesensor is responsible for noting the current temperature, no other class should havethat responsibility.</P><P>On the other hand, other classes might help deliver the necessary functionality.For example, while it might be the responsibility of the <TT>Sensor</TT> class tonote and log the current temperature, it might implement that responsibility by delegatingto a <TT>Log</TT> object the job of actually recording the data.</P><P>Maintaining a firm division of responsibilities makes your program easier to extendand maintain. When you decide to change the alarm system for an enhanced module,its interface to the log and to the sensors will be narrow and well defined. Changesto the alarm system should not affect the <TT>Sensor</TT> classes, and vice versa.</P><P>Should the <TT>HeatSensor</TT> have a <TT>ReportAlarm()</TT> function? All sensorswill need the ability to report an alarm. This is a good indication that <TT>ReportAlarm()</TT>should be a virtual method of <TT>Sensor</TT>, and that <TT>Sensor</TT> may be anabstract base class. It is possible that <TT>HeatSensor</TT> will chain up to <TT>Sensor</TT>'smore general <TT>ReportAlarm()</TT> method; the overridden function would just fillin the details it is uniquely qualified to supply.<H4 ALIGN="CENTER"><A NAME="Heading9"></A><FONT COLOR="#000077">How Are Alarms Reported?</FONT></H4><P>When your sensors report an alarm condition, they will want to provide a lot ofinformation to the object that phones the police and to the log. It may well be thatyou'll want to create a <TT>Condition</TT> class, whose constructor takes a numberof measurements. Depending on the complexity of the measurements, these too mightbe objects, or they might be simple scalar values such as integers.</P><P>It is possible that <TT>Condition</TT> objects are passed to the central <TT>Alarm</TT>object, or that <TT>Condition</TT> objects are subclassed into <TT>Alarm</TT> objects,which themselves know how to take emergency action. Perhaps there is no central object;⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -