|
|
|
|
|
|
|
on). Second, with the expanding use of OOD, more and more individuals and software companies are supplying libraries of prewritten classes and objects. In many cases, it is possible to browse through a class library, choose classes and objects you need for your problem, and assemble them to form a substantial portion of your program. Putting existing pieces together in this fashion is an excellent example of the building-block approach we discussed in Chapter 1. Third, OOD employs a concept called inheritance, which allows you to adapt an existing class to meet your particular needs without having to inspect and modify the source code for that class. Together, OOD, class libraries, and inheritance can dramatically reduce the time and effort required to design, implement, and maintain large software systems. |
|
|
|
|
|
|
|
|
In this section, we have presented only an introduction to OOD. A more complete discussion requires knowledge of topics that we explore in Chapters 4 through 14: flow of control, programmer-written functions, and structured data types. In Chapter 15, we learn how to write our own classes and create our own objects, and we return to OOD in Chapter 16. Until then, our programs are relatively small and we use top-down design to arrive at our problem solutions. |
|
|
|
|
|
|
|
|
An important perspective to keep in mind is that top-down design and object-oriented design are not separate, disjoint techniques. OOD decomposes a problem into objects. Objects not only contain data; they also have associated operations. The operations on objects require algorithms. Sometimes the algorithms are complicated and must be decomposed into subalgorithms by using top-down design. Experienced programmers are familiar with both methodologies and know when to use one or the other, or a combination of the two. |
|
|
|
| | |
|
|
|
|
As you create your top-down or object-oriented design, you are developing documentation for your program. Documentation includes the written problem specifications, design, development history, and actual code of a program. |
|
|
|
| |
|
|
|
|
Good documentation helps other programmers read and understand a program and is invaluable when software is being debugged and modified (maintained). If you haven't looked at your program for six months and need to change it, you'll be happy that you documented it well. Of course, if someone else has to use and modify your program, documentation is indispensable. |
|
|
|
| |
|
|
|
|
Documentation is both external and internal to the program. External documentation includes the specifications, the development history, and the design documents. Internal documentation includes the program format and self-documenting code |
|
|
|
|
|
|
|
|
|
(text box continues on next page) |
|
|
|
|
|