Preface

1. Preface

To build an object-oriented program is to construct a simulation. This is the singular, guiding concept of this text.

Goals

The fundamental concepts of programming are few; the hours of practice required to become a competent programmer are many. This text attempts to elucidate that most basic set of concepts required to start practicing the craft of programming. We intend to teach the students a world view. We wish to show them a way of seeing that will enable them to effectively and efficiently build simulations of the world they are trying to model. To this end, we want them to become comfortable using existing abstractions, and designing simple ones of their own. While this book uses the Java programming language as a vehicle, it is not about learning the details of that language. Rather, it hopes to teach a deeper language -- a language for problem solving, design, and systems understanding.

Method

We believe that the world view that we are trying to teach is already tacitly understood by many, if not all students. We hold this belief, because we find that the object-oriented paradigm is deeply rooted in our cultural traditions. The dominant trunk of the Western intellectual tradition holds that we inhabit a world of objects. These objects have qualities and are composed of other objects. We may efficiently classify groups of objects based on their qualities. Furthermore, we can hierarchicalize our classifications by abstracting the shared qualities of related sub-classifications.

Whether or not we agree with this particular ontology and epistemology, we cannot deny that it represents the dominant manner by which computer scientists in particular, and Western society in general, views the world, organizes systems of information, understands nature, and so on. Because it is so deeply ingrained in our cultural tradition, we feel that the instructor's job is to show their students that they are already quite practiced at using the object-oriented world view. In other words, most students are already quite good at thinking about the world in an object-oriented way, they just don't know it. To this end, we appeal to the student's intuitions about how they understand and talk about the world.

We believe in stimulating not just the symbolic - but also the enactive and iconic - reasoning abilities of the student. Like crafts such as carpentry, we find that the activity of programming is highly enactive and pattern-driven. To this end, we encourage a learning-by-doing approach, immersed in rich example domains and supported by powerful patterns. We engage the student's iconic reasoning abilities by encouraging them to draw pictures. Drawing pictures of the relationships between things is to object-oriented programming what procedural decomposition and flow-charting was to imperative programming. It is the meat and potatoes of understanding, designing, and implementing a system.

Finally, we avoid showing students the wrong way to solve a problem, to the extent possible. Experience has shown us that beginning programmers are easily imprinted with less-than-ideal approaches to problem solving and design. We prefer students to learn things the right way, rather than unlearn things learned the wrong way.

Differences

This book differs from most other texts in various ways. First and foremost, it is short. Keeping it short means that our words weigh more; it is easier to emphasize a point when it is not lost in a sea of text. A short book is also a light book; a student is more likely to bring it on the bus, take it to bed, or read it over coffee.

Second, the book emphasizes a data-driven approach to program design rather than the control-driven one that has traditionally dominated introductory texts. The latter approach was and is appropriate when the teaching languages are fundamentally imperative, such as Algol, Ada, Pascal, or C. However, large-scale object oriented systems, and indeed, object-oriented analysis and design shift the focus to understanding and designing the relationships amongst objects in an approriate manner. Consequently, the emphasis on algorithms and their implementation is necessarily diminished. Instructors trained in a technology of a prior generation (and this includes the authors) must accept that algorithmic thinking is no longer the only valid approach to problem solving and implementation. In fact, it could be argued, that such a paradigm is in fact at odds with generating good object-oriented designs.

Third, the book is not detail, rule, or syntax obsessed. It does not attempt to be a language reference for the Java language. There is a place for rules and details, but a concept-driven introductory text is not one of them.

Fourth, the book focuses minimally on graphics and GUI programming. Somehow these language features seem to have entered the canon of introductory texts, especially those that use Java as their teaching language. While we agree that there are (a few) important concepts in this kind of programming, we do not feel that they belong in the core of an introductory text.

Finally, the text is largely decoupled from specific, nonstandard Java classes. While many texts are written in support or in tandem with a set of Java classes used to simplify common programming tasks such as graphics programming or input/output, we have made an effort to stay within the realm of standard Java classes to the extent possible. We wish to decouple the principles and concepts from particular implementations thereof. Course-specific classes are certainly a good idea in most settings, but their details are best left to an appendix or lab manual.

What's missing

The lessons at the tail end of the book have yet to be written (including File I/O and possibly Inheritance), or are in rough form (as is the case with the section on Exceptions). Eventually, a lesson on Interfaces will be developed, and probably introduced near the middle of the book. We've found the concept of interface to be a critical one (especially if we avoid introducing/using inheritance early in the course), and will ultimately need to dedicate a lesson to it. Finally, a lesson on programming tools, including editors, compilers, and debuggers needs to be added. The details or suggestions regarding the use of specific tools (eg. BlueJ) would be best left to an appendix.