![]() Previous ![]() Contents ![]() Next |
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 youve 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-programmers 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.
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 Ive 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 Ive 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 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 its 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 Conways 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. Theyre 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.
Since Im assuming that the average reader has no previous Ada experience, Ive 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 youre in this situation, be warned that there are lots of new things in Ada 95 that werent in Ada 83. Ive 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 youll 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, youll 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 cant make any claims that this book provides a complete coverage of the language; the closest youll 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 Ive omitted are by and large minor details; the final chapter of the book tells you what Ive left out and why, and it points you towards several different sources of information if you want to find out about the things I didnt 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.