Crimes in Prison Summary of "A Laboratory for Teaching Object-Oriented Thinking"

"A Laboratory For Teaching Object-Oriented Thinking" describes a novel method for teaching programmers to think about programs in terms of objects instead of procedures in an attempt so solve the problem of programmers not adapting well to object-oriented programming. Programmers are introduced to the concepts of object-oriented programming without involving the specifics of any given language so that they can be taught to think in objects before they actually write object-oriented programs. The method consists of having programmers write down the class name, responsibilities and collaborators of each object on a separate note card, called a CRC card. Use of physical cards allows the programmer to represent relationships between objects spatially. The use of CRC cards has a high success rate for teaching programmers to solve problems using objects, rather than trying to add procedural techniques to an object-oriented design.

The authors set out to develop a method of teaching programmers to think about programs in terms of independent objects, rather than the entire program at once. They reduce the problem to teaching design of objects, as doing so removes the possibility of regressing to methods involving any global knowledge or control. The teaching method used by the authors does not use any particular language, or even computers. Instead, the class name, responsibilities and collaborators are written on note cards in order to provide an abstraction for object design. A great deal of effort is spent on selecting meaningful words to use for class names and responsibilities. The use of physical cards allows the programmer to model interaction between objects by arranging the cards spatially. The spatial layout makes it easy to identify areas where a new object needs to be added, and to determine what its responsibilities and collaborators might be. The design tends to naturally progress from what the programmer already knows to unknown areas that show up as physical holes in the layout of the cards.

The authors report good results using their method to teach real students. In one class, intended for students with moderate programming experience, a scenario is put to the students requiring them to describe an object-oriented design for an automatic banking machine using CRC cards. The authors report 100% success with over a hundred students. The method does not teach object-oriented programming, but does give programmers a framework for thinking in objects. Once able to think in objects, the details of a given object-oriented language are far more likely to make sense. Observation shows that less skilled programmers are more able to work with objects than with procedural designs. The authors speculate that their results are due to the fact that object designs are more related to the physical world than procedural programs are.

Response

The authors have developed an excellent method for teaching programmers to think about the design of objects. The use of physical cards creates a strong relationship between object design and the physical world, and requires programmers to give up the global thinking associated with procedural design in favor of local thinking about objects as independent entities working with each other. It may be desirable to use the authors' method to teach object-oriented design, however the authors have left out an important consideration about why it is difficult to teach programmers to think in objects: objects are not an appropriate abstraction for the majority of programming tasks. While it is possible to force almost any program in to an object-oriented model, doing so requires the programmer to create an unreasonably complex system, with a great deal of the program being code to enable data to move through a maze of objects. Object-oriented programming is popular today because it allows organizations to compensate for a lack of skilled developers. The authors' methods should be used for teaching object-oriented thinking, but care must be taken to encourage programmers to use objects only where appropriate.

Procedural programmers are used to describing software...

Thinking about software in terms of independent objects is a major paradigm shift, which is made easier by having a proper model for abstracting the ideas involved. Procedural programmers describe programs in terms of procedures, data storage and flow. The authors describe class name, responsibilities and collaborators as equivalent abstractions. The concepts the abstractions describe are intentionally dissimilar because the concepts are dissimilar. Procedural thinking in an object-oriented design results in a bad design, so it is desirable to avoid unnecessarily relating concepts from one to the other. The key difference is that object-oriented thinking involves treating objects as separate entities, sometimes even anthropomorphizing them. Thinking of objects as people who have responsibilities and collaborators helps avoid techniques that require an object to have information that a person with its responsibilities could not have except through telepathy.
The authors fail to mention that many programmers have difficulty with object-oriented design because the problems that many programs are written to solve do not consist entirely or even primarily of concepts that map neatly on to objects. Object-oriented design makes sense for many problems in computing. Filesystems are naturally object-oriented. Directories and files are the natural classes in a filesystem, with each directory or file being a separate instance. Graphical user interfaces are also natural candidates for representation as objects; there are windows, buttons, scroll bars, icons and various other elements that appear and behave as separate objects. It only makes sense that the underlying logic should treat them as such. It does not make as much sense to organize an automatic banking machine using objects. Functional programming is a far more natural approach for such a system. A functional design involves passing the return value of one function as an argument to another, often nested many levels deep, much like an algebraic expression. An example reimplementation of the authors' sample solution to the problem of designing a banking machine would include functions that have responsibilities similar to those of the classes used, but more directly represent the flow of information that the system must process.

Communication between people within an organization is one of the most time-consuming and error-prone activities that occurs in the workplace. Efficient workplaces give workers the ability to access as much information as possible directly, without having to ask for it from someone else. Complex object-oriented designs are much like large teams in an organization. The bulk of the team's time is spent coordinating between members instead of getting real work done. Inappropriate use of objects results in a large amount of wasted code just to let the objects communicate. Many popular languages require the use of objects for the entire program, instead of letting the programmer use them where appropriate and rely on other abstractions where they are appropriate. Such environments should be avoided by any organization that wants to allow its skilled programmers to be productive. Software components are not people, and should not be treated as such.

The authors point out that unskilled programmers are often more productive in an object-oriented environment. They fail to mention, perhaps because it is beyond the scope of their paper that the reason object-oriented programming has become as popular as it has in large organizations is that it does allow bad programmers to contribute without causing as many problems as it might in situations involving more global control over the program. Object-oriented programming helps localize the effect of bad designs to particular objects. It also allows for easy replacement of components deemed to be unacceptable. This effect is highly beneficial to large organizations that are not willing to spend the money and effort required to hire only intelligent, skilled programmers. Organizations that are more interested in developing high-quality software than in their ability to hire a steady supply of entry-level programmers should emphasize the use of abstractions that properly…