Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
without difficulty. For example: JButton button = new JButton("go"); 16.3 Using packages 225 If the import statement was omitted, we could still use the class JButton, but we would need to refer to it by its full name – javax.swing.JButton. This would be inconvenient and cumbersome. Hence we see the value of the import statement. If we only need to import an individual class, say JButton, from within a package, we can spell it out: import javax.swing.JButton; Using * means that we want to import all the classes within the named package. So if we need to use more than one from a package, it is simpler to use the * notation. SELF-TEST QUESTION 16.1 Classes called Monday, Tuesday, Wednesday, Thursday, Friday, Saturday and Sunday are grouped in a package called week. Write down the Java import statement that will be needed to use the class Friday. Write the statement to create an object friday of the class Friday. Write down the import statement that will be needed to use all the classes in the package. In C and C++, a program almost always begins with an include declaration. For a system package the declaration is typically: #include or, for a programmer’s own package: #include "myFile.h" The include statement is a directive to the compiler to include within the current source file a copy of the named file. A file with the suffix .h is, by convention, a header file and it is files of this type that normally appear in the include statement. A header file is a source code file that contains the declaration of the methods to be found within a package. These declarations are, in C terminology, the prototypes of the available methods – their names and parameters. The C and C++ languages have a rule that a method has to be declared (textually) before it can be used. When a declaration like this is present, the program can refer to the methods within the package described and it will compile successfully. Subsequently the object code of the packages is linked.
226 Chapter 16 ■ Programming in the large 16.4 ● Creating packages Suppose a system consists of three groups of classes: 1. classes that handle the user interface 2. classes that access the database 3. classes that handle the central logic of the program. We create three packages, named gui, database and logic. Next we need to ensure that individual classes are in the correct package. In Java this is accomplished using the package statement written at the head of the class. So, if we have a class named Login that handles the login part of the GUI, we write the following at the head of the class: package gui; public class Login If you omit a package statement, it means that the class is placed, by default, in a package with no name. SELF-TEST QUESTION 16.2 A class named Backup is to be placed in a package named database. Write the package statement and the class heading. 16.5 ● Scoping in large programs We have already seen how a program can access other packages using import or include statements. The issue is: What packages, methods and (rarely) variables are accessible to any given package? When you create and use packages, some new scope rules come into play. The essence is that classes within the same package can access each other very easily. When you write a method in Java, you specify that it is private, public, protected or simply give it no prefix. The prefix determines who can access the method: public means that the method is available to all. private means that it is accessible only within the class. protected means that the method can be used by any subclass. If you give a method no prefix, it means that the method is accessible from anywhere within the same package, but inaccessible from outside. This is also true of classes, constructors and variables. This means that the programmer can establish a close relationship between methods in the same package. This accords with the idea that classes in the same package are related to each other.
- 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
- 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: 224 Chapter 16 ■ Programming in t
- Page 251 and 252: 228 Chapter 16 ■ Programming in t
- Page 253 and 254: 230 Chapter 16 ■ Programming in t
- Page 255 and 256: 232 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 >=
226 Chapter 16 ■ <strong>Programming</strong> in the large<br />
16.4 ● Creating packages<br />
Suppose a system consists of three groups of classes:<br />
1. classes that handle the user interface<br />
2. classes that access the database<br />
3. classes that handle the central logic of the program.<br />
We create three packages, named gui, database and logic. Next we need to<br />
ensure that individual classes are in the correct package. In Java this is accomplished<br />
using the package statement written at the head of the class. So, if we have a class<br />
named Login that handles the login part of the GUI, we write the following at the<br />
head of the class:<br />
package gui;<br />
public class Login<br />
If you omit a package statement, it means that the class is placed, by default, in a<br />
package with no name.<br />
SELF-TEST QUESTION<br />
16.2 A class named Backup is to be placed in a package named database.<br />
Write the package statement and the class heading.<br />
16.5 ● Scoping in large programs<br />
We have already seen how a program can access other packages using import or<br />
include statements. The issue is: What packages, methods and (rarely) variables are<br />
accessible to any given package? When you create and use packages, some new scope<br />
rules come into play. The essence is that classes within the same package can access each<br />
other very easily.<br />
When you write a method in Java, you specify that it is private, public, protected<br />
or simply give it no prefix. The prefix determines who can access the method:<br />
public means that the method is available to all. private means that it is accessible<br />
only within the class. protected means that the method can be used by any subclass.<br />
If you give a method no prefix, it means that the method is accessible from anywhere<br />
within the same package, but inaccessible from outside. This is also true of classes, constructors<br />
and variables. This means that the programmer can establish a close relationship<br />
between methods in the same package. This accords with the idea that classes in<br />
the same package are related to each other.