Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
CHAPTER 12 This chapter explains: 12.1 ● Introduction Experienced programmers draw on half-remembered memories of software structures that they have used themselves or seen used in the past. An example of a simple programming pattern is the design of a program to find the largest number in an array of numbers. The simplest algorithm uses a variable to record the largest value that has yet been encountered. The program starts at the beginning of the array and proceeds item by item, examining each number, updating this variable as necessary: largest = list[0] index = 0 while index largest then largest = list[index] end if index = index + 1 end while Design patterns ■ how to use design patterns during development ■ several major design patterns ■ some valuable anti-patterns. This is clearly a small piece of program that is easily constructed by any experienced programmer, but to novice programmers, seeing this is something of a revelation. And once seen, the programmer never forgets it. Or at least the programmer remembers the idea of what is needed, rather than the detail. This is a software pattern. Over a >
152 Chapter 12 ■ Design patterns period of time, experienced programmers build up a large repertoire of memories of programming patterns such as this one. A number of patterns have been identified, given names, cataloged and documented in catalogs or books. These patterns are available for off-the-shelf use, just as classes are available in class libraries. Software engineering patterns are patterns on a larger scale than the simple program seen above. The established patterns specify the structure of useful software at the architectural level. In object-oriented development, this means structures expressed in terms of classes and their interrelationships. The strength of design patterns is that good design ideas are recorded, given a name, and explained with the aid of examples. This extends the vocabulary of software developers. It also extends the repertoire of ideas that they can use without reinventing the wheel. To make use of patterns, the software engineer needs some recollection of the standard patterns. This is obtained by browsing a patterns catalog prior to a project. The engineer thereby retains some memory (perhaps only a partial recollection) of the patterns, then, during the early phase of software architectural design, the engineer realizes that one or more patterns may be useful. They then consult the catalog to confirm the appropriateness of the pattern and see exactly how to use it. The next step is to use the pattern as part of the design. In summary the stages are: 1. browse a design pattern catalog, to obtain some feel for the available patterns 2. embark on a new design with an awareness of the patterns 3. recognize the need for one of the established patterns 4. consult the catalog to check the applicability of the pattern 5. use the catalog for information on the how to use the pattern 6. use the pattern as part of the design. As well as architectural structure, patterns are available for such domains as user interfaces, file systems and multithreading. Patterns are also provided for activities such as testing and project management. In order to use design patterns the programmer needs considerable experience and understanding of OOD and OOP. Just as there are patterns (which are valuable structures) so there are anti-patterns, which are undesirable structures. The reason for identifying and cataloguing anti-patterns is to avoid them. We look at one such pattern. In this chapter we present a number of useful patterns and use the cyberspace invaders game as an example in explaining some of the patterns. 12.2 ● Inheritance It bears repeating that one of the major goals of the object-oriented paradigm is to produce reusable software components – components which can be reused both within the application in which they were generated but also in future applications.
- Page 124 and 125: count = 0 loop: count = count + 1 i
- Page 126 and 127: > 8.2 Case study 103 A statement th
- Page 128 and 129: start button event create defender
- Page 130 and 131: 8.3 ● Discussion Abstraction One
- Page 132 and 133: Exercises 109 skill. On the other h
- Page 134 and 135: CHAPTER 9 This chapter explains: 9.
- Page 136 and 137: 9.2 Identifying data flows 113 Noti
- Page 138 and 139: 9.3 Creation of a structure chart 1
- Page 140 and 141: SELF-TEST QUESTION 9.4 Discussion 1
- Page 142 and 143: Exercises 119 During the second sta
- Page 144 and 145: CHAPTER 10 This chapter explains:
- Page 146 and 147: In English, this reads: 10.2 A simp
- Page 148 and 149: 10.2 A simple example 125 Now comes
- Page 150 and 151: 10.4 Multiple input and output stre
- Page 152 and 153: Process header Process issue 10.4 M
- Page 154 and 155: 10.5 Structure clashes 131 As seen
- Page 156 and 157: 10.5 Structure clashes 133 Let us r
- Page 158 and 159: 10.6 Discussion 135 ■ teachable -
- Page 160 and 161: Exercises 137 2. a control block, s
- Page 162 and 163: CHAPTER 11 Object-oriented design T
- Page 164 and 165: Figure 11.1 The cyberspace invaders
- Page 166 and 167: SELF-TEST QUESTION 11.1 Derive info
- Page 168 and 169: 11.5 Class-responsibility-collabora
- Page 170 and 171: 11.7 ● Discussion Summary 147 OOD
- Page 172 and 173: 11.11 Compare and contrast the prin
- Page 176 and 177: 12.3 Delegation 153 The concepts of
- Page 178 and 179: 12.5 Factory method 155 The followi
- Page 180 and 181: 12.8 Model, view controller (observ
- Page 182 and 183: Figure 12.4 Pipe and Filter pattern
- Page 184 and 185: Figure 12.6 Layers in a distributed
- Page 186 and 187: Answers to self-test questions 163
- Page 188 and 189: CHAPTER 13 Refactoring This chapter
- Page 190 and 191: 13.3 ● Move Method 13.6 Inline Cl
- Page 192 and 193: class Sprite Instance variables x y
- Page 194 and 195: Summary Summary 171 it is making po
- Page 196: PART C PROGRAMMING LANGUAGES
- Page 199 and 200: 176 Chapter 14 ■ The basics and a
- Page 201 and 202: 178 Chapter 14 ■ The basics > > >
- Page 203 and 204: 180 Chapter 14 ■ The basics > Ear
- Page 205 and 206: 182 Chapter 14 ■ The basics > Cas
- Page 207 and 208: 184 Chapter 14 ■ The basics > > >
- Page 209 and 210: 186 Chapter 14 ■ The basics > } }
- Page 211 and 212: 188 Chapter 14 ■ The basics Unfor
- Page 213 and 214: 190 Chapter 14 ■ The basics Ada d
- Page 215 and 216: 192 Chapter 14 ■ The basics The w
- Page 217 and 218: 194 Chapter 14 ■ The basics In a
- Page 219 and 220: 196 Chapter 14 ■ The basics > str
- Page 221 and 222: 198 Chapter 14 ■ The basics Answe
- Page 223 and 224: CHAPTER 15 Object-oriented programm
CHAPTER<br />
12<br />
This chapter explains:<br />
12.1 ● Introduction<br />
Experienced programmers draw on half-remembered memories of software structures<br />
that they have used themselves or seen used in the past. An example of a simple programming<br />
pattern is the design of a program to find the largest number in an array of<br />
numbers. The simplest algorithm uses a variable to record the largest value that has yet<br />
been encountered. The program starts at the beginning of the array and proceeds item<br />
by item, examining each number, updating this variable as necessary:<br />
largest = list[0]<br />
index = 0<br />
while index largest then<br />
largest = list[index]<br />
end if<br />
index = index + 1<br />
end while<br />
Design patterns<br />
■ how to use design patterns during development<br />
■ several major design patterns<br />
■ some valuable anti-patterns.<br />
This is clearly a small piece of program that is easily constructed by any experienced<br />
programmer, but to novice programmers, seeing this is something of a revelation. And<br />
once seen, the programmer never <strong>for</strong>gets it. Or at least the programmer remembers<br />
the idea of what is needed, rather than the detail. This is a software pattern. Over a<br />
>