Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
Figure 16.3 Single inheritance JFrame Circle Game JFrame Thread Game Figure 16.4 Multiple inheritance (supported in C++ but not in Java) 16.8 Multiple interfaces 231 Sometimes we would like a class to inherit from more than one superclass as described in the following class header and shown in Figure 16.4. public class Game extends JFrame, Thread // error But this heading is wrong because it attempts to extend two classes. This would be called multiple inheritance. Some languages, such as C++, permit multiple inheritance while Java does not. Multiple inheritance allows a class to inherit sets of methods from a number of classes, and it is therefore potentially very powerful. If we think about classification systems in science and nature, it is often the case that objects belong to more than one class. We humans, for example, belong to one gender class, but also to a class that likes a particular type of music. So we all belong in one inheritance tree for gender, another for musical taste, another for mother tongue, and so on. Interfaces provide a way of emulating a facility similar to multiple inheritance. This is because, while a class can only extend a single class, it can implement any number of interfaces. Multiple interfaces are illustrated in Figure 16.5. This example is coded in Java as follows: public class Game extends JFrame implements InterfaceA, InterfaceB If Game inherited from InterfaceA and InterfaceB, it would inherit a set of methods from InterfaceA and InterfaceB. But instead Game is implementing interfaces InterfaceA and InterfaceB, and these interfaces have no methods on offer.
232 Chapter 16 ■ Programming in the large JFrame Figure 16.5 Multiple interfaces InterfaceA Game What this means is that class Game agrees to provide the methods described in InterfaceA and InterfaceB – that Game has agreed to conform to certain behavior. The code for implementing InterfaceA and InterfaceB has to be written as part of the class Game. 16.9 ● Separate compilation InterfaceB A programming language is ill suited for the development of large, complex programs if it does not provide facilities for the separate compilation of program modules. Large programs must necessarily be developed by teams of programmers; individual programmers must be able to work independently and at the same time be able to access programs written by other members of the team. Programming language support is required for the integration of routines that have been developed separately. Additional support in this area is often provided by environmental tools, such as linkers, cross-reference generators, file librarians and source code control systems. What support should the programming language itself provide? We suggest the following: ■ independent compilation of program modules ■ easy access to libraries of precompiled software ■ the ability to integrate together components written in different languages ■ strong type checking across module boundaries ■ the ability to avoid the unnecessary recompilation of precompiled modules. One of the foremost reasons for the continued popularity of Fortran is the tremendous resource of reusable software available to scientists and engineers through the readily accessible libraries of scientific and engineering subroutines. Fortran provides independent compilation of modules at the subroutine level and easy access to library routines but performs no run-time checking of calls to external routines. It is the responsibility of the programmer to check that the correct number and type of parameters are used in the calling program. Java and similar languages provide far greater support for separate compilation than Fortran. Classes may be compiled as separate modules with strong type checking across module boundaries to ensure that they are used in accordance with their specifications. The specification and implementation of a class may be compiled in two separate parts.
- 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
- Page 241 and 242: 218 Chapter 15 ■ Object-oriented
- Page 243 and 244: 220 Chapter 15 ■ Object-oriented
- Page 245 and 246: 222 Chapter 16 ■ Programming in t
- Page 247 and 248: 224 Chapter 16 ■ Programming in t
- Page 249 and 250: 226 Chapter 16 ■ Programming in t
- Page 251 and 252: 228 Chapter 16 ■ Programming in t
- Page 253: 230 Chapter 16 ■ Programming in t
- Page 257 and 258: 234 Chapter 16 ■ Programming in t
- Page 259 and 260: 236 Chapter 16 ■ Programming in t
- Page 261 and 262: 238 Chapter 17 ■ Software robustn
- Page 263 and 264: 240 Chapter 17 ■ Software robustn
- Page 265 and 266: 242 Chapter 17 ■ Software robustn
- Page 267 and 268: 244 Chapter 17 ■ Software robustn
- Page 269 and 270: 246 Chapter 17 ■ Software robustn
- Page 271 and 272: 248 Chapter 17 ■ Software robustn
- Page 273 and 274: 250 Chapter 17 ■ Software robustn
- Page 275 and 276: 252 Chapter 17 ■ Software robustn
- Page 277 and 278: 254 Chapter 17 ■ Software robustn
- Page 279 and 280: 256 Chapter 17 ■ Software robustn
- Page 281 and 282: 258 Chapter 17 ■ Software robustn
- Page 283 and 284: 260 Chapter 18 ■ Scripting GNU/Li
- Page 285 and 286: 262 Chapter 18 ■ Scripting In sum
- Page 288: PART D VERIFICATION
- Page 291 and 292: 268 Chapter 19 ■ Testing We begin
- Page 293 and 294: 270 Chapter 19 ■ Testing within a
- Page 295 and 296: 272 Chapter 19 ■ Testing Test num
- Page 297 and 298: 274 Chapter 19 ■ Testing if (a >=
- Page 299 and 300: 276 Chapter 19 ■ Testing 3. apply
- Page 301 and 302: 278 Chapter 19 ■ Testing made con
- Page 303 and 304: 280 Chapter 19 ■ Testing 19.3 Dev
232 Chapter 16 ■ <strong>Programming</strong> in the large<br />
JFrame<br />
Figure 16.5 Multiple interfaces<br />
<br />
InterfaceA<br />
Game<br />
What this means is that class Game agrees to provide the methods described in<br />
InterfaceA and InterfaceB – that Game has agreed to con<strong>for</strong>m to certain behavior.<br />
The code <strong>for</strong> implementing InterfaceA and InterfaceB has to be written as part of<br />
the class Game.<br />
16.9 ● Separate compilation<br />
<br />
InterfaceB<br />
A programming language is ill suited <strong>for</strong> the development of large, complex programs<br />
if it does not provide facilities <strong>for</strong> the separate compilation of program modules. Large<br />
programs must necessarily be developed by teams of programmers; individual programmers<br />
must be able to work independently and at the same time be able to access<br />
programs written by other members of the team. <strong>Programming</strong> language support is<br />
required <strong>for</strong> the integration of routines that have been developed separately. Additional support<br />
in this area is often provided by environmental tools, such as linkers, cross-reference<br />
generators, file librarians and source code control systems. What support should the<br />
programming language itself provide? We suggest the following:<br />
■ independent compilation of program modules<br />
■ easy access to libraries of precompiled software<br />
■ the ability to integrate together components written in different languages<br />
■ strong type checking across module boundaries<br />
■ the ability to avoid the unnecessary recompilation of precompiled modules.<br />
One of the <strong>for</strong>emost reasons <strong>for</strong> the continued popularity of Fortran is the tremendous<br />
resource of reusable software available to scientists and engineers through the<br />
readily accessible libraries of scientific and engineering subroutines. Fortran provides<br />
independent compilation of modules at the subroutine level and easy access to library<br />
routines but per<strong>for</strong>ms no run-time checking of calls to external routines. It is the<br />
responsibility of the programmer to check that the correct number and type of parameters<br />
are used in the calling program.<br />
Java and similar languages provide far greater support <strong>for</strong> separate compilation than<br />
Fortran. Classes may be compiled as separate modules with strong type checking across<br />
module boundaries to ensure that they are used in accordance with their specifications.<br />
The specification and implementation of a class may be compiled in two separate parts.