The book you are holding represents a new direction in introductory computer science instruction. For more than a decade, we''ve been hearing that object-oriented programming (OOP) is "the wave of the future" and that it has a central place in the computer science curriculum. Recently, the debate has moved from whether OOP belongs in the curriculum to where it belongs. Now, with this book, we present our answer: We think OOP should be taught at the beginning. We don''t mean that OOP should be introduced sometime during the first course; OOP should be part of the very first chapter. What''s more, the premise of this book is that students need to see all of OOP at the beginning. Students then can write significant object-oriented programs using all of the OOP mechanisms, from inter-object communication via parameters and pointers, to inheritance, virtual methods, and polymorphism, before learning most features of the programming language, such as flow of control, arithmetic, or even base types. Then, as students learn more about the constructs of the language, they can use the tools of object-oriented design to create even more powerful, extensible programs.
The power of OOP, we have discovered, can be diluted if students do not see all of the machinery at the beginning, tempting as it might be to delay concepts such as pointers, virtual methods, and polymorphism. It has been our experience that students'' programs become too convoluted because they must compensate for missing functionality. Our approach cultivates good object-oriented design habits from the start and puts OOP power to work as early as possible, to allow construction of programs of significant size and complexity. For those of us who have been teaching structured (procedural) programming, teaching OOP at the start requires a significant shift in mindset. In teaching this new way ourselves, we have occasionally felt uncomfortable giving up "tried and true" pedagogy for this new approach. However, the payoff has been terrific. It''s exciting to watch students design and build interactive paint programs less than a month into the course, then create a working arcade game (like Tetris) just halfway through a semester. It''s satisfying to know that students go into later courses with a solid start in object-oriented design and programming.
We hope that you too find this approach exciting and worthwhile. Parsing the Title Our title, Object-Oriented Programming in Pascal: A Graphical Approach, may not win any awards for brevity, but we do think it accurately reflects what is truly important and unique about this book. To elaborate, allow us to deconstruct our title. Object-Oriented Programming Object-oriented design and programming form the foundation of this book. In the first eight chapters (Part I) of the book, we devote our full attention to all the key concepts of OOP: defining objects and instances, sending messages, creating communication links, inheritance, virtual methods, and polymorphism. To make sure these concepts aren''t just so many big words, we show how they play out in practice by examining complete Pascal programs. However, these programs do not require learning much Pascal syntax; essentially, all we need are the statements to declare classes, instances, and variables; message passing and parameters; a brief introduction to pointers; and assignment. In the rest of the book, we cover the traditional topics such as arithmetic, flow of control, and arrays, but always from an OOP point of view.
Throughout Part I, we also place a heavy emphasis on the design of programs. Knowing how to program is more than learning the syntax of particular language; a good programmer is one who can take a specification and design a solution that will meet the user''s needs. An object-oriented approach requires that we think about the program as a system of objects from the beginning of the design process. We emphasize that the objects in the system should be designed for re-use. Although this concept may be a little more abstract, since we are forced to think about more than the task currently at hand, we think it pays off well. In the early chapters, we focus on the use (and re-use) of objects in existing libraries; later, we spend more time designing new objects that can be used in multiple programs. Learning the technique of "systems thinking" requires practice with systems. Besides the numerous exercises (which we will describe in more detail shortly), we also provide examples of programs, where we start with a specification, walk through the design, and show the development of the code.
Chapter 8, for example, walks through the development of a simple interactive paint program and ties together the ideas of OOP described in Part I. Of course, we don''t leave objects behind once we finish those chapters. Object-oriented design and programming techniques permeate the book. Pascal This text uses Pascal. Specifically, we have written all of the code using Borland Pascal for Windows. Borland provides extensive object libraries with all of its Pascal products. The Borland Pascal for Windows environment is quite friendly, with its debugging and help facilities that both novice and expert programmers can appreciate. As an abbreviation, we refer to the Pascal language and the object-oriented extensions as OOPas (for Object-Oriented Pascal).
Beyond the tools that come with Borland Pascal for Windows, we''ve also added our own library of objects for Windows called GP (for Graphics Package). These additional classes are not meant as a substitute for the complete package provided by Borland; rather, they are a basic set of graphic user interface (GUI) tools that provide a way to get started with object-oriented programming. GP has enough functionality that students can use it in advanced courses as well. If you want to run the programs in this book, you need both Borland Pascal for Windows and the GP library. (Details on how to obtain GP appear a little later in this Preface.) Some of you may be wondering why we didn''t use another language; after all, Pascal is not inherently an object-oriented language. We spend a good deal of time examining C++ as well as more "purely" object-oriented languages such as Eiffel and Self. We believe C++ is too large, idiosyncratic, and unsafe for introductory students.
It is all too possible for introductory students to get lost in the complexity and obscure run-time errors of C++, when we would rather that they focus on the basics of programming and design. It''s been our experience that when we do teach C++ (in the fourth course in our computer science sequence), our OOPas-trained students transfer their knowledge quite well. Languages like Eiffel and Self hold a great deal of promise, but, at the moment, are not in common enough use. A Graphical Approach We kept the same subtitle as our earlier work, Pascal on the Macintosh: A Graphical Approach (Addison-Wesley, 1987), for the same reasons. First, interactive graphics programming has become even more crucial for today''s computer professionals; the vast majority of programs written on all platforms have graphical user interfaces and the bulk of code in interactive programs lies in their GUIs. Indeed, the reason most of our examples involve various aspects of GUIs is that GUIs are the most common denominator of the types of programs students will write after they complete their studies, and GP gives them a solid foundation in this important area of software. The graphical approach also reinforces our emphasis on objects. To learn how to use objects, students need a library, and it made sense for that library to have a focus.
The library could focus on a specific discipline, such as engineering or music, but that would necessarily limit our examples to ideas from that discipline and would assume reader knowledge of that discipline. Rather, we chose graphics as the focus so that very little prior knowledge--essentially, just some basic ideas from high school algebra and geometry--was required for students to understand what the objects are and what they do. We''ve also found that graphics is particularly attractive for students who are new to programming. It''s easy for students to make the connections between objects in their programs and graphical objects that appear on the screen. The graphical user interface is a familiar paradigm for today''s students, who are increasingly familiar with computers prior to taking the introductory course. Finally, graphics programs are easier to debug, provide more satisfying results, and are simply more fun than traditional number- and character-crunching programs. The idea of "a graphical approach" also implies that we use graphics to teach programming concepts. You will see illustrations generously distributed throughout the book, especially to explain some of the more notoriously difficult concepts, such as recursion, linked lists, and object interrelationships.
FEATURES The Graphics Package (GP) Library When we began teaching our objects-first approach in 1993, we began with the hypothesis that students could learn OOP from the start only if they were given a set of interesting, building-block objects from which they could create programs. First, however, the students needed access to a set of objects that were powerful enough to build applications, yet could be understood, as we said earlier, with little background in any particular domain. The result is the Graphics Package (GP) library. Parts of GP are explained in detail in the text; Appendix D also contains descriptions of the GP classes students will need to use. Rather than just read about GP, however, students can explore how it works by loading the library into Borland Pascal. With t.