IEEE Std 1016-1998, Recommended Practice for Software Design Descriptions. 1739
This document contains the IEEE-ANSI standard for software-design
1740
descriptions. It describes what should be included in a software-design
1741
document.
1742
IEEE Std 1471-2000. Recommended Practice for Architectural Description of 1743
Software Intensive Systems, Los Alamitos, CA: IEEE Computer Society Press. 1744
This document is the IEEE-ANSI guide for creating software architecture
1745
specifications.
1746
CHECKLIST: Design in Construction
1747
Design Practices
1748
Have you iterated, selecting the best of several attempts rather than the first
1749
attempt?
1750
Have you tried decomposing the system in several different ways to see
1751
which way will work best?
1752
Have you approached the design problem both from the top down and from
1753
the bottom up?
1754
Have you prototyped risky or unfamiliar parts of the system, creating the
1755
absolute minimum amount of throwaway code needed to answer specific
1756
questions?
1757
Has you design been reviewed, formally or informally, by others?
1758
Have you driven the design to the point that its implementation seems
1759
obvious?
1760
Have you captured your design work using an appropriate technique such as
1761
a Wiki, email, flipcharts, digital camera, UML, CRC cards, or comments in
1762
the code itself?
1763
Design Goals
1764
Does the design adequately address issues that were identified and deferred
1765
at the architectural level?
1766
Is the design stratified into layers?
1767
Are you satisfied with the way the program has been decomposed into
1768
subsystems, packages, and classes?
1769
Are you satisfied with the way the classes have been decomposed into
1770
routines?
1771
Are classes designed for minimal interaction with each other?
1772
Are classes and subsystems designed so that you can use them in other
1773
systems?
1774
Will the program be easy to maintain?
1775
Is the design lean? Are all of its parts strictly necessary?
1776
Does the design use standard techniques and avoid exotic, hard-to-
1777
understand elements?
1778
Overall, does the design help minimize both accidental and essential
1779 complexity? 1780 1781
Key Points
1782• Software’s Primary Technical Imperative is managing complexity. This is 1783
accomplished primarily through a design focus on simplicity.
1784
• Simplicity is achieved in two general ways: minimizing the amount of
1785
essential complexity that anyone’s brain has to deal with at any one time and
1786
keeping accidental complexity from proliferating needlessly.
1787
• Design is heuristic. Dogmatic adherence to any single methodology hurts
1788
creativity and hurts your programs.
1789
• Good design is iterative; the more design possibilities you try, the better
1790
your final design will be.
1791
• Information hiding is a particularly valuable concept. Asking, “What should
1792
I hide?” settles many difficult design issues.
1793
• Lots of useful, interesting information on design is available outside this
1794
book. The perspectives presented here are just the tip of the iceberg.
6
1Working Classes
2 Contents 36.1 Class Foundations: Abstract Data Types (ADTs)
4
6.2 Good Class Interfaces
5
6.3 Design and Implementation Issues
6
6.4 Reasons to Create a Class
7
6.5 Language-Specific Issues
8
6.6 Beyond Classes: Packages
9
Related Topics
10
Design in construction: Chapter 5
11
Software architecture: Section 3.5
12
Characteristics of high-quality routines: Chapter 7
13
The Pseudocode Programming Process: Chapter 9
14
Refactoring: Chapter 24
15
In the dawn of computing, programmers thought about programming in terms of
16
statements. Throughout the 1970s and 1980s, programmers began thinking about
17
programs in terms of routines. In the twenty-first century, programmers think
18
about programming in terms of classes.
19
A class is a collection of data and routines that share a cohesive, well-defined
20
responsibility. A class might also be a collection of routines that provides a
21
cohesive set of services even if no common data is involved. A key to being an
22
effective programmer is maximizing the portion of a program that you can safely
23
ignore while working on any one section of code. Classes are the primary tool
24
for accomplishing that objective.
25
This chapter contains a distillation of advice in creating high quality classes. If
26
you’re still warming up to object-oriented concepts, this chapter might be too
27
advanced. Make sure you’ve read Chapter 5. Then start with Section 6.1,
28
“Abstract Data Types (ADTs),” and ease your way into the remaining sections.
29
CC2E.COM/ 0665
If you’re already familiar with class basics, you might skim Section 6.1 and then
30
dive into the discussion of good class interfaces in Section 6.2. The “Additional
31
Resources” section at the end of the chapter contains pointers to introductory
32
reading, advanced reading, and programming-language–specific resources.
33
6.1 Class Foundations: Abstract Data Types
34
(ADTs)
35
An abstract data type is a collection of data and operations that work on that
36
data. The operations both describe the data to the rest of the program and allow
37
the rest of the program to change the data. The word “data” in “abstract data
38
type” is used loosely. An ADT might be a graphics window with all the
39
operations that affect it; a file and file operations; an insurance-rates table and
40
the operations on it; or something else.
41
Understanding ADTs is essential to understanding object-oriented programming.
42
Without understanding ADTs, programmers create classes that are “classes” in
43
name only—in reality, they are little more than convenient carrying cases for
44
loosely related collections of data and routines. With an understanding of ADTs,
45
programmers can create classes that are easier to implement initially and easier
46
to modify over time.
47
Traditionally, programming books wax mathematical when they arrive at the
48
topic of abstract data types. They tend to make statements like “One can think of
49
an abstract data type as a mathematical model with a collection of operations
50
defined on it.” Such books make it seem as if you’d never actually use an
51
abstract data type except as a sleep aid.
52
Such dry explanations of abstract data types completely miss the point. Abstract
53
data types are exciting because you can use them to manipulate real-world
54
entities rather than low-level, implementation entities. Instead of inserting a node
55
into a linked list, you can add a cell to a spreadsheet, a new type of window to a
56
list of window types, or another passenger car to a train simulation. Tap into the
57
power of being able to work in the problem domain rather than at the low-level
58
implementation domain!
59