Ada 95 - The Craft of Object-Oriented Programming(2).pdf

(4439 KB) Pobierz
Preface
http://www.it.bton.ac.uk/staff/je/adacraft/preface.htm
Previous
Contents
Next
Preface
The word ‘craft’ in the title of this book has been chosen deliberately. There have been books published with titles such as ‘The Art’ or ‘The Science’ of
programming, but I feel that neither of these titles is really appropriate for a textbook like this. In Art, you have a blank canvas and are free to express
yourself as the spirit moves you in order to produce Beauty; in Science, you are constrained by ‘the laws of physics’ to produce Truth. A craft, on the other
hand, is less free than Art but less constrained than Science. Truth and Beauty are both involved in the process, but Art provides a blank canvas which is
rarely found in real-life programming. There is almost always some previous system which has to be conformed to: an existing database or file format, or the
peculiarities of a particular operating system. Science searches for Truth, but there is little truth in most programs; only fairly trivial programs are susceptible
to correctness proofs at present. Most programs are unwieldy beasts, made like Frankenstein’s monster from leftover fragments of previous generations of
programs, and neither Art nor Science takes account of this.
Craft skills are concerned with making the best out of available resources. If you are given some wood and asked to make a piece of furniture from it, you
have to work within the confines of what that wood will allow. If the wood is knotty at a particular place, you may have to revise your initial plans in order to
work around the knots, or you may have to discard some of the wood and find some more which matches the piece you’ve been given. Craftsmanship is
concerned with the ability to work around problems like this. In programming, you are rarely presented with a clean sheet and invited to design the next
world-beating program; you are usually presented with an existing program and a list of problems to be resolved. How you choose to solve those problems is
a measure of your craftsmanship. The existing program will undoubtedly be full of ‘knots’ which you have to work around. A good craftsman will be able to
produce an elegant result from a knotty problem. ‘Elegant’ is often treated as a synonym for ‘artistic’; I feel that the word ‘crafty’ is, in its original sense, a
more accurate translation.
Craftsmanship depends on having a good set of tools to hand. In the realm of programming, the tools are techniques, algorithms, ways of doing things, ways
of approaching particular types of problem, and of course programming languages which support those approaches. Object-oriented programming is the latest
addition to the craftsman-programmer’s toolkit. It is not an ultimate solution in the Scientific sense of ensuring that programs which use it will be guaranteed
to be correct; it is not an Artistic solution that frees you from the need to fit in with what already exists. It is a Crafty solution that allows you to design things
in such a way that when they are broken you will be able to take them apart and fix them, and when they need extending you will be able to add on the extra
features with a minimum of effort.
How this book is organised
Many programming textbooks that I’ve seen concentrate on teaching the features of a particular language, and use numerous small ‘blank canvas’ examples
to illustrate those features. What seems to be ignored all too often are the real-life situations where the problems deal with an existing legacy of programs or
data which must be maintained and modified in some way. What I’ve tried to do in this book is to concentrate on a relatively small number of examples
which are capable of improvement and to refine them throughout the book. The result is that the order of topics is primarily example driven; new topics are
introduced by adding extra ‘bells and whistles’ to existing examples. The examples start with the traditional ‘Hello world’ program and gradually get more
and more elaborate, culminating in two reasonably sized examples: an electronic diary and a spreadsheet. Although these are only about a thousand lines of
code each in their final versions, they nevertheless show the sort of maintenance problems that arise in ‘real world’ applications and illustrate how careful
design can alleviate such problems.
The book is in three parts. The
first part
deals with the fundamentals of Ada programming: how to do input and output, how if statements and loops work,
what procedures, functions and packages are all about, how to define your own data types, how to handle exceptions. At this stage the examples are
necessarily tiny; although I deal with program design in
chapter 3
when I reach the first example large enough that design merits a separate discussion, the
next few chapters concentrate more on introducing the building blocks of Ada using variations on earlier examples. Instructors should of course continue to
emphasise the design techniques I’ve introduced when students are expected to develop new programs as exercises. At the end of the first part, an electronic
appointments diary provides a larger example which merits a
chapter entirely devoted to design and debugging,
although at this stage the design is
deliberately na‹ve.
By the end of the first part, the reader will have been presented with two examples which will be carried further in the next two parts: an electronic
appointments diary and a simple desk calculator. These next two parts concentrate on introducing maintenance problems and introducing new approaches and
techniques for dealing with these problems. In my experience the real problems of programming only become apparent when you have to maintain an
existing legacy of code, and you only learn to design programs so that they are capable of being maintained in the future when you yourself have been on the
receiving end of maintenance problems.
The
second part
deals with abstract data types; it begins by taking the example from the end of the first part and proposing some possible maintenance
scenarios. I use these as an excuse for revising the designs I’ve already proposed in the first part. The early chapters in the second part deal with improving
the appointments diary from
chapter 8,
while the
last chapter
returns to the calculator example from the first part. Some new implementation techniques are
introduced: linked lists, generics, opaque types and recursion are all investigated. The effort involved in dealing with the proposed maintenance scenarios
should reveal what a mess poor programming practices can get you into, and should hopefully provide an incentive to master ways of designing programs so
that this sort of effort will be minimised if you ever have to make maintenance changes to programs that you write.
The
third and final part
is concerned with using the object-oriented programming features of Ada 95 to develop extensible programs. The features of Ada
described here provide the essential difference between Ada 83 and Ada 95. This part considers maintenance scenarios which affect not just the
(re)implementation of existing features but also the capacity of the current design to accommodate new requirements. What happens when you want your
1 of 2
9/21/2011 3:19 PM
Preface
http://www.it.bton.ac.uk/staff/je/adacraft/preface.htm
existing appointments diary to cope with different types of appointment? What if at some future date you want to incorporate a new type of appointment into
your existing systems? What if you want to extend your existing calculator to cope with the extra requirements of a spreadsheet? What if you want a
spreadsheet that updates itself in real time? These are the sort of maintenance problems that arise most commonly in the real world; implementation is
irrelevant to users, but the ability to add new features is crucial. And it is up to the craftsman-programmer to reach into his or her toolbox and to craft a
solution with the tools available; the final part of this book shows how it’s possible.
In my opinion, the best way to learn any programming language is to use it to do something that interests you. I first learnt to program because I was
interested in John Conway’s ‘Game of Life’ which was popular in the early 1970s, and I wanted something that would let me find out the eventual fate of the
R-pentomino. I never succeeded in this because I got sidetracked into programming as an end in itself! Electronic diaries and spreadsheets should be familiar
enough applications to all readers, and I hope that this will make them reasonably interesting. They’re large enough to be challenging, but not so large as to
require a book twice the size of this one. Adopting a project of a similar size (e.g. a text editor) and working on it in parallel with studying this book is the
best way I can think of to become a good Ada programmer. Consider the traps and pitfalls I introduce in my examples and think about similar traps and
pitfalls that might befall you in your own programs. Practice makes perfect, after all.
Who this book is for
I’ve aimed this book squarely at the beginning programmer learning Ada 95 as a first language, mainly because Ada is becoming one of the most popular
languages used in introductory programming courses. I teach one of these myself. If you’re an experienced programmer you might find the going a bit slow
in the first couple of chapters, but Ada is sufficiently different from most other languages that it’s worth reading these chapters anyway just in case you miss
something important. If you’re an experienced programmer it won’t take you long to get through them. At the end of the book there is also a glossary and a
set of appendices for reference; the final version of the packages developed in the text is also included as
Appendix D.
You can get the full set of examples
from the website for this book (http://www.it.brighton.ac.uk/staff/je/adacraft/) or by anonymous FTP from
ftp://ftp.brighton.ac.uk/pub/je/adacraft.
They’ve
been tested using the GNAT compiler, which is also freely available by anonymous FTP from New York University (see
chapter 20
for details).
Since I’m assuming that the average reader has no previous Ada experience, I’ve completely ignored Ada 83. Mentioning Ada 83 in a book for someone with
no prior knowledge who wants to learn Ada 95 would just be confusing. This leaves readers who are experienced Ada 83 programmers in a delicate position;
the temptation will be to say `oh yeah, I know this stuff!’ and to skip to the next chapter. If you’re in this situation, be warned that there are lots of new things
in Ada 95 that weren’t in Ada 83. I’ve included a summary of the syntax of Ada as
Appendix A
which also includes references to the chapters where each
feature of the language is covered; readers with a knowledge of Ada 83 can use this to locate information about new features of Ada 95. However, you may
well find that by skipping chapters to get to the ‘interesting’ bits you will miss the descriptions of some of the underlying features, in which case you’ll have
to go back for another look at the bits you skipped over the first time. Also, since the examples are built up a little bit at a time, you’ll sometimes find you
need to go back a few chapters to look at the early stages of the examples.
Ada is a big language. I can’t make any claims that this book provides a complete coverage of the language; the closest you’ll get to a complete coverage is
the Annotated Reference Manual. I can, however, guarantee that this book is easier to read than the Annotated Reference Manual! The examples in this book
have been carefully chosen to allow me to use them to introduce most of the features of Ada. The topics I’ve omitted are by and large minor details; the
final
chapter
of the book tells you what I’ve left out and why, and it points you towards several different sources of information if you want to find out about the
things I didn’t tell you. Despite the omissions, I hope you will find this an interesting, informative and enjoyable book.
— John English (email:
je@brighton.ac.uk)
Brighton, October 1995
Previous
Contents
Next
This file is part of
Ada 95: The Craft of Object-Oriented Programming
by John English.
Copyright ©
John English
2000. All rights reserved.
Permission is given to redistribute this work for non-profit educational use only, provided that all the constituent files are distributed without change.
$Revision: 1.3 $
$Date: 2002/02/21 13:00:00 $
2 of 2
9/21/2011 3:19 PM
Ada 95: Contents
http://www.it.bton.ac.uk/staff/je/adacraft/
Next
Ada 95: The Craft of Object-Oriented Programming
by
John English
(originally published by Prentice Hall, 1997)
Copyright ©
John English
2001. All rights reserved.
Permission is given to redistribute this work for non-profit educational use only, provided that all the constituent files are distributed unchanged
and without charge.
This book, originally published by Prentice Hall in 1996, was taken out of print in 2001 and the rights to the book were subsequently returned to me by
Pearson (the successor company to Prentice Hall). I have decided to make it available online in HTML format, and at the same time I have corrected several
errata which were present in the printed editions of the book. It’s perfectly possible that I might have missed some, or even introduced some brand-new ones,
as part of the process of transforming the text into HTML. If you spot any mistakes, please
let me know
so I can correct the master copy, which can be found
at
http://www.it.bton.ac.uk/staff/je/adacraft/.
Downloadable copies are available as
http://www.it.bton.ac.uk/staff/je/adacraft/bookhtml.zip
(in zip format for Windows systems) or as
http://www.it.bton.ac.uk/staff/je/adacraft/bookhtml.tar.gz
(a gzipped tarball for Unix systems). Each distribution also includes the complete set of examples
from the book, both for Windows (adacraft.zip) and for Unix (adacraft.tar.gz).
Contents
Preface
Part One: Fundamentals
1. Programming concepts
1.1
What is a program?
1.2
Readability, maintainability, portability and reusability
1.3
Specifications and implementations
1.4
Abstract data types
1.5
Generics
1.6
Inheritance and polymorphism
2. Fundamentals of Ada
2.1
Hello, world!
2.2
Names in Ada
2.3
Program layout
2.4
Context clauses
2.5
Strings
2.6
A simple calculator
2.7
Procedure specifications
Exercises
3. Statements
3.1
If statements
3.2
Assignment statements
3.3
Compound conditions
3.4
The case statement
3.5
Range tests
3.6
The null statement
3.7
Loops
3.8
The calculator program revisited
3.9
Exception handling
Exercises
4. Procedures, functions and packages
4.1
Zeller's Congruence
4.2
Declaring procedures
4.3
Declaring functions
1 of 5
9/21/2011 3:28 PM
Ada 95: Contents
http://www.it.bton.ac.uk/staff/je/adacraft/
4.4
Scope and lifetime
4.5
Separate compilation
4.6
Subprograms as library units
4.7
Packages
4.8
Child packages
Exercises
5. Defining new data types
5.1
Standard data types
5.2
Integers
5.3
Subtypes
5.4
Derived types
5.5
Modular integers
5.6
Real types
5.7
Numeric literals
5.8
Constants
5.9
Enumerations
5.10
The type Boolean
5.11
The type Character
5.12
Renaming declarations
Exercises
6. Composite data types
6.1
Record types
6.2
Strings
6.3
Declaring array types
6.4
Unconstrained types
6.5
For loops revisited
6.6
A simple sorting procedure
6.7
Multidimensional arrays
6.8
Discriminants
6.9
Limited types
6.10
Using packages with data types
Exercises
7. Exceptions
7.1
The importance of exception handling
7.2
Declaring exceptions
7.3
Re-raising exceptions
7.4
Getting information about exceptions
7.5
File input/output
Exercises
8. Program design and debugging
8.1
Stepwise refinement
8.2
Initial design
8.3
Diary package design
8.4
Debugging the main program
8.5
Displaying the appointments
8.6
Adding new appointments
8.7
Deleting appointments
8.8
Loading and saving
8.9
Assessing the program
Exercises
Part Two: Abstract Data Types
9. Private types
9.1
The need for abstraction
9.2
Package design
9.3
Private types
9.4
Full and partial views
9.5
Deferred constants
9.6
The package body
9.7
Overloaded operators
9.8
‘Use type’ clauses
9.9
A word of caution
9.10
The package Ada.Calendar
Exercises
10. Designing with abstract data types
10.1
The design process revisited
10.2
Separating out the user interface
2 of 5
9/21/2011 3:28 PM
Ada 95: Contents
http://www.it.bton.ac.uk/staff/je/adacraft/
10.3
Designing the model
10.4
Defining the view package
10.5
Implementing the ADT packages
10.6
Diary operations
10.7
Maintenance issues
Exercises
11. Dynamic memory allocation
11.1
Access types
11.2
Linked lists
11.3
Doubly linked lists
11.4
Iterators
11.5
Deallocating memory
11.6
Designing a linked list diary
11.7
Implementing a linked list diary
11.8
General access types
11.9
Access parameters and discriminants
Exercises
12. Generics
12.1
Generic packages
12.2
Generic parameters
12.3
Revising the diary package
12.4
A generic sorting procedure
12.5
Generics and general access types
Exercises
13. Building a calculator
13.1
Handling operator precedence
13.2
A stack package
13.3
An improved calculator
13.4
Implementing the stack package
13.5
Opaque types
13.6
Formalising the syntax of expressions
13.7
A recursive descent parser
Exercises
Part Three: Designing extensible software
14. Tagged types
14.1
Extending existing software
14.2
Variant records
14.3
Tagged types
14.4
Inheriting primitive operations
14.5
A package for representing meetings
14.6
The dangers of inheritance
14.7
Inheritance or containment?
Exercises
15. Polymorphism and dispatching
15.1
Class-wide types
15.2
Dispatching
15.3
Abstract types
15.4
An object-oriented diary
15.5
Stream input/output
15.6
Other diary operations
15.7
Extending the diary
Exercises
16. Controlled types
16.1
Memory leaks
16.2
User-defined finalisation
16.3
Smart pointers
16.4
User-defined assignment
16.5
Testing controlled types
Exercises
17. An object-oriented calculator
17.1
Expression-handling objects
17.2
Tokens
17.3
Token extraction
17.4
Expression evaluation
17.5
Was it worth it?
Exercises
3 of 5
9/21/2011 3:28 PM

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin