Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
13.3 ● Move Method 13.6 Inline Class 167 A method is written within a class, but it uses very little of its current class. Instead it uses many of the facilities of another class. The remedy is to move the method from one class to the other. In the game, the software needs to check whether pairs of items have collided, for example, a laser and an alien. For clarity, this collision detection is carried out by a method. This method is part of both class Laser and class Alien. This creates strong coupling between the objects. Instead move the method to a class that is responsible for checking collisions between all the objects in the game. In general, moving a method may be necessary when: ■ a class has too many methods ■ a class has high coupling with another class. Moving a method is a common refactoring situation. 13.4 ● Move Data A variable is declared within a class, but another class uses it more. The remedy is to move the variable declaration. Clearly this also means moving the get and set methods. 13.5 ● Extract Class A class has become too large and complex; it is doing the work of two classes. The remedy is to create a new class, extracting the appropriate variables and methods from the old class. Ideally classes emerge from design as self-contained components that model some element of the application. In practice, as design proceeds, classes sometimes take on extra roles. Variables and methods are gradually added until the class becomes cumbersome. It becomes a candidate for fission. 13.6 ● Inline Class A class is very small, or it does not do very much. The remedy is to incorporate it into some other class – ideally the class that uses it the most.
168 Chapter 13 ■ Refactoring One way in which a class can become very small is when it has been the subject of the Move Method and the Move Variable refactorings, so that it has become sucked dry. This illustrates how many of the refactorings are interconnected – using one leads to using another, and so on. SELF-TEST QUESTION 13.1 Compare the factoring Inline Class with the factoring Extract Class. 13.7 ● Identify composition or inheritance Once we have identified the classes within a software system, the next step is to review the relationships between the classes. The classes that make up the software collaborate with each other to achieve the required behavior, but they use each other in different ways. There are two ways in which classes relate to each other: 1. composition – one object creates another object from a class using new. An example is a window object that creates a button object. 2. inheritance – one class inherits from another. An example is a class that extends the library Frame class. The important task of design is to distinguish these two cases, so that inheritance can be successfully applied or avoided. One way of checking that we have correctly identified the appropriate relationships between classes is to use the “is-a” or “has-a” test: ■ the use of the phrase “is-a” in the description of an object (or class) signifies that it is probably an inheritance relationship. ■ the use of the phrase “has-a” indicates that there is no inheritance relationship. Instead the relationship is composition. (An alternative phrase that has the same meaning is “consists-of ”.) We return to the cyberspace invaders game, designed in Chapter 11, seeking to find any inheritance relationships. If we can find any such relationships, we can simplify and shorten the program, making good use of reuse. In the game, several of the classes – Defender, Alien, Laser and Bomb – incorporate the same methods. These methods are: getX, getY, getHeight and getWidth that obtain the position and size of the graphical objects. We will remove these ingredients from each class and place them in a superclass. We will name this class Sprite, since the word sprite is a commonly used term for a moving graphical object in games programming. The UML class diagram for the Sprite class is:
- 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 174 and 175: CHAPTER 12 This chapter explains: 1
- 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 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
- Page 225 and 226: 202 Chapter 15 ■ Object-oriented
- Page 227 and 228: 204 Chapter 15 ■ Object-oriented
- Page 229 and 230: 206 Chapter 15 ■ Object-oriented
- Page 231 and 232: 208 Chapter 15 ■ Object-oriented
- Page 233 and 234: 210 Chapter 15 ■ Object-oriented
- Page 235 and 236: 212 Chapter 15 ■ Object-oriented
- Page 237 and 238: 214 Chapter 15 ■ Object-oriented
- Page 239 and 240: 216 Chapter 15 ■ Object-oriented
168 Chapter 13 ■ Refactoring<br />
One way in which a class can become very small is when it has been the subject of<br />
the Move Method and the Move Variable refactorings, so that it has become sucked<br />
dry. This illustrates how many of the refactorings are interconnected – using one leads<br />
to using another, and so on.<br />
SELF-TEST QUESTION<br />
13.1 Compare the factoring Inline Class with the factoring Extract Class.<br />
13.7 ● Identify composition or inheritance<br />
Once we have identified the classes within a software system, the next step is to review<br />
the relationships between the classes. The classes that make up the software collaborate<br />
with each other to achieve the required behavior, but they use each other in different<br />
ways. There are two ways in which classes relate to each other:<br />
1. composition – one object creates another object from a class using new. An example<br />
is a window object that creates a button object.<br />
2. inheritance – one class inherits from another. An example is a class that extends the<br />
library Frame class.<br />
The important task of design is to distinguish these two cases, so that inheritance<br />
can be successfully applied or avoided. One way of checking that we have correctly<br />
identified the appropriate relationships between classes is to use the “is-a” or “has-a”<br />
test:<br />
■ the use of the phrase “is-a” in the description of an object (or class) signifies that it<br />
is probably an inheritance relationship.<br />
■ the use of the phrase “has-a” indicates that there is no inheritance relationship.<br />
Instead the relationship is composition. (An alternative phrase that has the same<br />
meaning is “consists-of ”.)<br />
We return to the cyberspace invaders game, designed in Chapter 11, seeking to<br />
find any inheritance relationships. If we can find any such relationships, we can simplify<br />
and shorten the program, making good use of reuse. In the game, several of the<br />
classes – Defender, Alien, Laser and Bomb – incorporate the same methods. These<br />
methods are: getX, getY, getHeight and getWidth that obtain the position and<br />
size of the graphical objects. We will remove these ingredients from each class and<br />
place them in a superclass. We will name this class Sprite, since the word sprite is a<br />
commonly used term <strong>for</strong> a moving graphical object in games programming. The<br />
UML class diagram <strong>for</strong> the Sprite class is:
Change language