?? 018.htm
字號:
<HTML><HEAD><meta http-equiv="Content-Type" content="text/html; charset=GB2312"><TITLE>-->Learn C++ in 21 Days-->Day 18</TITLE>
<META NAME="888" CONTENT=" Learn C++ in 21 Days Day 18">
<META NAME="888" CONTENT=" - Learn C++ in 21 Days - Day 18">
<style>
<!--
#page {position:absolute; z-index:0; left:0px; top:0px}
.tt3 {font: 9pt/12pt "宋體"}
.tt2 {font: 12pt/15pt "宋體"}
a {text-decoration:none}
a:hover {color: blue;text-decoration:underline}
-->
</style>
</HEAD>
<p align="center"><script src="../../../1.js"></script> </p>
<TD CLASS="tt3" VALIGN="top" width="8%" bgcolor="#ffffff"><strong><A HREF="019.htm"><FONT style="FONT-SIZE: 9pt">后一頁</font></A><BR>
<A HREF="017.htm"><FONT style="FONT-SIZE: 9pt">前一頁</font></A><BR>
<A HREF="index.html"><FONT style="FONT-SIZE: 9pt">回目錄</font></A><BR>
<TD class="tt2" bgcolor="#ffffff" width="100%"><center><B><FONT style="FONT-SIZE: 16.5pt" COLOR="#FF6666" FACE="楷體_GB2312">Day 18</FONT></B></center>
<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>
<BR>
<P>
<HR SIZE="4">
<BR>
<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 Analysis
and Design</FONT></H2>
<P>It is easy to become focused on the syntax of C++ and to lose sight of how and
why you use these techniques to build programs. Today you will learn
<BR>
<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>
<BR>
<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 determine
how the program will be built, what classes will be used, and so forth; and then
programmers implement the design and architecture. By the time the design and architecture
is given to the programmer, it is complete; all the programmer needs to do is implement
the required functionality.</P>
<P>Even if the waterfall method worked, it would probably be a poor method for writing
good programs. As the programmer proceeds, there is a necessary and natural feedback
between what has been written so far and what remains to be done. While it is true
that 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 programming
begins, is a function of the size of the program. A highly complex effort, involving
dozens of programmers working for many months, will require a more fully articulated
architecture 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 be
expanded and enhanced over many years. Many programmers enjoy working at the bleeding
edge of technology; they tend to write programs whose complexity pushes at the limits
of their tools and understanding. In many ways, C++ was designed to extend the complexity
that a programmer or team of programmers could manage.</P>
<P>This chapter will examine a number of design problems from an object-oriented
perspective. The goal will be to review the analysis process, and then to understand
how you apply the syntax of C++ to implement these design objectives.
<H3 ALIGN="CENTER"><A NAME="Heading4"></A><FONT COLOR="#000077">Simulating an Alarm
System</FONT></H3>
<P>A simulation is a computer model of a part of a real-world system. There are many
reasons to build a simulation, but a good design must start with an understanding
of what questions you hope the simulation will answer.</P>
<P>As a starting point, examine this problem: You have been asked to simulate the
alarm 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 dining
room, 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 which
has 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 one
window in the garage.</P>
<P>Normal access to the house is through the front door. Additionally, the kitchen
has a sliding glass door, and the garage has two doors for the cars and one door
for 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 phone
and next to the bed. The grounds are alarmed as well, though these are carefully
calibrated 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 chirp
when the alarm has been tripped. If the alarm is not disabled within a setable amount
of time, the police are called. If a panic button is pushed, the police are called
immediately.</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 power
supply, 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, "How
long might a sensor be broken before anyone notices?" or "Is there a way
to defeat the window alarms without the police being notified?"</P>
<P>Once you understand the purpose of the simulation you will know what parts of
the real system the program must model. Once that is well understood, it becomes
much 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 interface
and to focus only on the components of the "problem space." A first approximation
of 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>
<BR>
<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>
<BR>
</DL>
<BR>
<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 also
simulate rooms, perhaps floors, and possibly groups of people such as owners and
police.</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 is
no such thing as a sensor per se. This is a good indication that sensor is an abstract
data type (ADT).</P>
<P>As an ADT, the class sensor would provide the complete interface for all types
of sensors, and each derived type would provide the implementation. Clients of the
various sensors would use them without regard to which type of sensor they are, and
they 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 sensors
do (rather than how they work). For example, are sensors passive devices or are they
active? Do they wait for some element to heat up, a wire to break, or a piece of
caulk to melt, or do they probe their environment? Perhaps some sensors have only
a binary state (alarm state or okay), but others have a more analog state (what is
the current temperature?). The interface to the abstract data type should be sufficiently
complete 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 will
be required to meet the specification. For example, if a log is to be kept, probably
a timer will be needed; should the timer poll each sensor or should each sensor file
its 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 in
your 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 inheritance
from <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 could
imagine a design in which the alarm system has a setting for <TT>MaxTemp</TT>. The
alarm system asks the heat sensor what the current temperature is, compares it to
the maximum temperature, and sounds the alarm if it is too hot. One could argue that
this violates the principle of encapsulation. Perhaps it would be better if the alarm
system didn't know or care what the details are of temperature analysis; arguably
that should be in the <TT>HeatSensor</TT>.</P>
<P>Whether or not you agree with that argument, it is the kind of decision you want
to focus on during the analysis of the problem. To continue this analysis, one could
argue that only the <TT>Sensor</TT> and the <TT>Log</TT> object should know any details
of 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 set
of responsibilities, and no other class having the same responsibilities. If the
sensor is responsible for noting the current temperature, no other class should have
that 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 to
note and log the current temperature, it might implement that responsibility by delegating
to 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 extend
and 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. Changes
to 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 sensors
will 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 an
abstract base class. It is possible that <TT>HeatSensor</TT> will chain up to <TT>Sensor</TT>'s
more general <TT>ReportAlarm()</TT> method; the overridden function would just fill
in 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 of
information to the object that phones the police and to the log. It may well be that
you'll want to create a <TT>Condition</TT> class, whose constructor takes a number
of measurements. Depending on the complexity of the measurements, these too might
be objects, or they might be simple scalar values such as integers.</P>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -