Software Engineering For Students: A Programming Approach Part 20 pot

168 Chapter 13 ■ Refactoring
SELF-TEST QUESTION
13.1 Compare the factoring Inline Class with the factoring Extract Class.
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 sim-
plify 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:
13.7
●
Identify composition or inheritance
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.
BELL_C13.QXD 1/30/05 4:23 PM Page 168
13.7 Identify composition or inheritance 169
class Sprite
Instance variables
x
y
height
width
Methods
getX
getY
getHeight
getWidth
Readers might see this more clearly if we look at the code. The Java code for the
class
Sprite is as follows:
public class Sprite {
protected int x, y, width, height;
public int getX() {

return x;
}
public int getY() {
return y;
}
public int getWidth() {
return width;
}
public int getHeight() {
return height;
}
}
The classes Defender, Alien, Laser and Bomb now inherit these methods from this
superclass
Sprite. Checking the validity of this design, we say “each of the classes
Defender, Alien, Laser and Bomb is a Sprite”. Figure 13.1 shows these rela-
tionships in a class diagram. Remember that an arrow points from a subclass to a
superclass.
>
>
BELL_C13.QXD 1/30/05 4:23 PM Page 169
Polymorphism enables objects that are similar to be treated in the same way. This means
classes that share some common superclass. A section of code that uses a number of
if
statements (or a case statement) should be subject to scrutiny because it may be that
13.8
●
Use polymorphism
170 Chapter 13 ■ Refactoring
We have now successfully identified inheritance relationships between classes in the

game program. This concludes the refactoring – we have transformed the design into a
better design.
When we see common methods or variables in two or more classes, they become
candidates for inheritance, but we need to be careful because delegation may be more
appropriate. So we need to distinguish between the two. To sum up, the two kinds of
relationship between classes are as follows.
Relationship between classes test Java code involves
SELF-TEST QUESTION
13.2 Analyze the relationships between the following groups of classes (are
they is-a or has-a):
1. house, door, roof, dwelling
2. person, man, woman
3. car, piston, gearbox, engine
4. vehicle, car, bus.
Inheritance is-a extends
Composition has-a or consists-of new
Sprite
Defender Alien Laser Bomb
Figure 13.1 Class diagram for inherited components in the game
BELL_C13.QXD 1/30/05 4:23 PM Page 170
Summary 171
Summary
Refactoring means improving the architectural structure of a piece of software.
This can be done at the end of design or during design.
A number of useful refactorings have been identified, given names and cataloged.
The refactorings described in this chapter are:
■ Encapsulate Data
■ Move Method
■ Extract Class
■ Inline Class

■ identify composition or inheritance
■ use polymorphism.
it is making poor use of polymorphism. The purpose of the
if statements may be to
distinguish the different classes and thereby take appropriate action. But it may be sim-
pler to refactor the class, eliminate the
if statements and exploit polymorphism.
In the game program, we identified the commonalities in a number of classes –
Alien,
Defender, Bomb and Laser. We placed the common factors in a superclass called Sprite.
Now we can treat all the objects uniformly. We place the game objects in an array list
named
game and write the following code to display them:
for (int s = 0; s < game.size(); s++) {
Object item = game.get(s);
Sprite sprite = (Sprite) item;
sprite.display(paper);
}
which is much neater than a whole series of if statements.
The idea of taking a design and changing it can be a surprise. It may seem akin to cre-
ating an ad hoc design and then experimenting with it. It has the flavor of hacking.
Some people argue that a good design method should produce a good design – that it
should not need improvement. Equally, many developers are reluctant to tinker with an
architectural design that has been created according to sound principles. However,
refactoring has a respectable pedigree. It recognizes that a perfect initial design is unlike-
ly and it offers a number of possible strategies for improving a structure. A refactoring
such as Extract Method gives the developer the green light to modify an initial design.
Note that refactoring implies that iteration is commonly used during OOD.
13.9
●

Discussion
BELL_C13.QXD 1/30/05 4:23 PM Page 171
172 Chapter 13 ■ Refactoring
Answers to self-test questions
13.1 Inline Class is the opposite of the Extract Class.
13.2 1. a house has-a roof and a door. A house is-a dwelling
2. a man (and a woman) is-a person
3. an engine has-a piston and a gearbox and an engine
4. a car and a bus is-a vehicle.
Exercises
•
13.1 In the cyberspace invaders game, we have already carried out a refactoring, identify-
ing a superclass Sprite and applying inheritance. Some of the graphical objects in the
game move vertically (bombs, lasers) while some move horizontally (alien, defender).
Consider new superclasses MovesVertically and MovesHorizontally and
draw the class diagrams for this new inheritance structure. Assess whether this refac-
toring is useful.
13.2 At what stage do you stop the process of refactoring?
13.3 Examine your architectural designs for the software case studies (Appendix A) and
see if refactoring is achievable and desirable.
BELL_C13.QXD 1/30/05 4:23 PM Page 172
PART
C
PROGRAMMING
LANGUAGES
BELL_CPARTC.QXD 1/30/05 4:30 PM Page 173
BELL_CPARTC.QXD 1/30/05 4:30 PM Page 174
Everyone involved in programming has their favorite programming language, or lan-
guage feature they would like to have available. There are many languages, each with
their proponents. So this chapter is probably the most controversial in this book. This

chapter is not a survey of programming languages, nor is it an attempt to recommend
one language over another. Rather, we wish to discuss the features that a good pro-
gramming language should have from the viewpoint of the software engineer. We limit
our discussion to “traditional” procedural languages, such as Fortran, Cobol, Ada, C++,
Visual Basic, C# and Java. (Other approaches to programming languages are functional
programming and logic programming.)
The main theme of this chapter is a discussion of the basic features a language should
provide to assist the software development process. That is, what features encourage the
development of software which is reliable and maintainable?
A significant part of the software engineer’s task is concerned with how to model,
within a program, objects from some problem domain. Programming, after all, is large-
ly the manipulation of data. In the words of Niklaus Wirth, the designer of Pascal,
“Algorithms + Data Structures = Programs” – which asserts the symbiosis between data
14.1
●
Introduction
CHAPTER
14
The basics
This chapter reviews the basic features of a programming
language suitable for software engineering, including:
■ design principles
■ syntax
■ control structures
■ methods and parameters
■ data typing
■ simple data structures.
BELL_C14.QXD 1/30/05 4:23 PM Page 175
176 Chapter 14 ■ The basics
and actions. The data description and manipulation facilities of a programming lan-

guage should therefore allow the programmer to represent “real-world” objects easily
and faithfully. In recent years, increasing attention has been given to the problem of
providing improved data abstraction facilities for programmers. We discuss this in
Chapter 15 on programming language features for OOP.
As we shall see, most mainstream programming languages have a small core and all
the functionality of the language is provided by libraries. This chapter addresses this
core. Facilities for programming in the large are reviewed in Chapter 16. Other features
of languages – exceptions and assertions – are dealt with in Chapter 17.
It is important to realize that programming languages are very difficult animals to
evaluate and compare. For example, although it is often claimed that language X is a
general purpose language, in practice languages tend to be used within particular
communities. Thus, Cobol has been the preferred language of the information sys-
tems community, Fortran, the language of the scientist and engineer, C, the language
of the systems programmer and Ada, the language for developing real-time or embed-
ded computer systems. Cobol is not equipped for applications requiring complex
numerical computation, just as the data description facilities in Fortran are poor and
ill suited to information systems applications.
Programming languages are classified in many ways. For example, “high-level” or
“low-level”. A high-level language, such as Cobol, Visual Basic or C#, is said to be
problem-oriented and to reduce software production and maintenance costs. A low-level
language, such as assembler, is said to be machine-oriented, facilitating the program-
mer’s complete control over the efficiency of their programs. Between high- and low-
level languages, another category, the systems implementation language or high-level
assembler, has emerged. Languages such as C attempt to bind into a single language the
expressive power of a high-level language and the ultimate control which only a language
that provides access at the register and primitive machine instruction level can provide.
Languages may also be classified using other concepts, such as whether they are weakly
or strongly typed. This is discussed below.
Simplicity, clarity and orthogonality
One school of thought argues that the only way to ensure that programmers will con-

sistently produce reliable programs is to make the programming language simple. For
programmers to become truly proficient in a language, the language must be small and
simple enough that it can be understood in its entirety. The programmer can then use
the language with confidence, probably without recourse to a language manual.
14.3
●
Design principles
14.2
●
Classifying programming languages and features
BELL_C14.QXD 1/30/05 4:23 PM Page 176
14.3 Design principles 177
Cobol and PL/1 are examples of languages which are large and unwieldy. For
example, Cobol currently contains about 300 reserved words. Not surprisingly, it is a
common programming error mistakenly to choose a reserved word as a user-defined
identifier. What are the problems of large languages? Because they contain so many
features, some are seldom used and, consequently, rarely fully understood. Also, since
language features must not only be understood independently, but also in terms of their
interaction with each other, the larger the number of features, the more complex it will
be and the harder to understand their interactions. Although smaller, simpler languages
are clearly desirable, the software engineer of the near future will often have to wrestle
with existing large, complex languages. For example, to meet the requirements laid
down by its sponsors, the US Department of Defense, the programming language Ada
is a large and complex language requiring a 300-page reference manual to describe it.
The clarity of a language is also an important factor. In recent years, there has been
a marked and welcome trend to design languages for the programmers who program
in them rather than for the machines the programs are to run on. Many older languages
incorporate features that reflect the instruction sets of the computers they were orig-
inally designed to be executed on. As one example, consider the Fortran arithmetic if
statement, which has the following form:

if (expression) label1,label2,label3
This statement evaluates expression and then branches to one of the statements
labeled
label1, label2, or label3 depending on whether the result is positive, zero,
or negative. The reason for the existence of this peculiar statement is that early IBM
machines had a machine instruction which compared the value of a register to a value
in memory and branched to one of three locations. The language designers of the
1960s were motivated to prove that high-level languages could generate efficient code.
Although we will be forever grateful to them for succeeding in proving this point, they
introduced features into languages, such as Cobol and Fortran, which are clumsy and
error-prone from the programmer’s viewpoint. Moreover, even though the languages
have subsequently been enhanced with features reflecting modern programming ideas,
the original features still remain.
A programming language is the tool that programmers use to communicate their
intentions. It should therefore be a language which accords with what people find nat-
ural, unambiguous and meaningful – in other words, clear. Perhaps language designers
are not the best judges of the clarity of a new language feature. A better approach to
testing a language feature may be to set up controlled experiments in which subjects are
asked to answer questions about fragments of program code. This experimental psy-
chology approach is gaining some acceptance and some results are discussed in the sec-
tion on control abstractions.
A programmer can only write reliable programs if he or she understands precisely
what every language construct does. The quality of the language definition and sup-
porting documentation are critical. Ambiguity or vagueness in the language definition
erodes a programmer’s confidence in the language. It should not be necessary to have
to write and run a program fragment to confirm the semantics of some language feature.
BELL_C14.QXD 1/30/05 4:23 PM Page 177