Java Reference
In-Depth Information
do not exist. There are only two things that can happen to a software system: either it is continu-
ously improved and adapted, or it will disappear.
This discussion is central to this topic, because it strongly influences how we view the tasks and
skills required of a programmer or software engineer. You might be able to tell that the authors
of this topic strongly favor the software growth model over the waterfall model. 4
As a consequence, certain tasks and skills become much more important than they would be in
the waterfall model. Software maintenance, code reading (rather than just writing), designing
for extendibility, documentation, coding for understandability, and many other issues we have
mentioned in this topic take their importance from the fact that we know there will be others
coming after us who have to adapt and extend our code.
Viewing a piece of software as a continuously growing, changing, adapting entity, rather than
a static piece of text that is written and preserved like a novel, determines our views about how
good code should be written. All the techniques we have discussed throughout this topic work
toward this.
Exercise 13.13 In which ways might the cinema booking system be adapted or extended
in the future? Which changes are more likely than others? Write down a list of possible future
Exercise 13.14 Are there any other organizations that might use booking systems similar to
the one we have discussed? What significant differences exist between the systems?
Exercise 13.15 Do you think it would be possible to design a “generic” booking system
that could be adapted or customized for use in a wide range of different organizations with
booking needs? If you were to create such a system, at what point in the development pro-
cess of the cinema system would you introduce changes? Or would you throw that one away
and start again from scratch?
Using design patterns
In earlier chapters, we have discussed in detail some techniques for reusing some of our work
and making our code more understandable to others. So far, a large part of these discussions has
remained at the level of source code in single classes.
A design pattern
is a description of a
common comput-
ing problem and
a description of a
small set of classes
and their interac-
tion structure that
helps to solve that
As we become more experienced and move on to design larger software systems, the imple-
mentation of single classes is not the most difficult problem any more. The structure of the
overall system—the complex relationships between classes—becomes harder to design and to
understand than the code of individual classes.
An excellent book describing the problems of software development and some possible approaches to
solutions is The Mythical Man-Month by Frederick P. Brooks Jr., Addison-Wesley. Even though the
original edition is nearly 40 years old, it makes entertaining and very enlightening reading.
Search WWH ::

Custom Search