Textbook in PDF format

Diagrams. Draw them by hand. Diagrams are the programmer’s doodling language. Using a tool that draws them for you from the existing code defeats the purpose. Assigning students to do so defeats the purpose of learning to doodle. Stuff. Conventional text books at this level present object-oriented programming as an extension of imperative programming. The reasoning is that computations interact with the real world where physical objects change their state all the time. For example, people get sick and become patients; balls drop from a hand and change location; and so on. Therefore, the reasoning goes, computational objects, which represent physical objects, encapsulate and hide the state of the world for which they are responsible and, on method calls, they change state. Naturally, people begin to express computations as sequences of assignment statements that change the value of variables and fields (instance variables). We disagree with this perspective and put classes and the design of classes into the center of our approach. In “How to Design Programs” we defined classes of data. As we developed larger and larger programs, it became clear that the design of a program requires the introduction of many classes of data and the development of several functions for each class. The rest is figuring out how the classes of data and their functions related to each other. In this volume, we show students how object-oriented programming languages such as C# and Java support this effort with syntactic constructs. We also refine the program design discipline