Object Thinking Think Like an Object

Object Thinking = Think Like an Object

The essential thinking difference is easily stated: Think like an object. Of course, this statement gets its real meaning by contrast with the typical approach to software development: Think like a computer. Thinking like a computer is the prevailing mental habit of traditional developers. And, as David Parnas noted, ^[5] it s a bad habit:

The easiest way to describe the programming method used in most projects today was given to me by a teacher who was explaining how he teaches programming. Think like a computer, he said. He instructed his students to begin by thinking about what the computer had to do first and to write that down. They would then think about what the computer had to do next and continue in that way until they had described the last thing the computer would do. Most of today s textbooks demonstrate the same method, although it has been improved by allowing us to describe the computer s thoughts in larger steps and later to refine those large steps into a sequence of smaller steps.

This intuitively appealing method works well ”on problems too small to matter. As we continue in our attempt to think like a computer, the amount we have to remember grows and grows. The simple rules defining how we got to certain points in a program become more complex as we branch there from other points. The simple rules defining what the data mean become more complex as we find other uses for existing variables and add new variables . Eventually, we make an error.

In many of our computer systems there are several sources of information and several outputs that must be controlled. This leads to a computer that might be thought of as doing several things at once. If the sequence of external events cannot be predicted in advance, the sequence of actions taken by the computer also is not predictable. Any attempt to design these programs by thinking things through in the order that the computer will execute them leads to confusion and results in systems that nobody can understand completely.

When there is more than one computer in a system, the software not only appears to be doing more than one thing at a time, it really is doing many things at once. There is no sequential program that one can study. Any attempt to think like a computer system is obviously hopeless.

Programmers have tried to improve their working methods using a variety of software design approaches. However, when they get down to writing executable programs, they revert to the conventional way of thinking.

It should be clear that writing and understanding very large real-time programs by thinking like a computer will be beyond our intellectual capabilities. How can it be that we have so much software that is reliable enough for us to use it? The answer is simple; programming is a trial and error craft. People write programs without any expectation that they will be right the first time. They spend at least as much time testing and correcting errors as they spent writing the initial program. Software is released for use, not when it is known to be correct, but when the rate of discovering errors slows down to one that management considers acceptable.

The kind of thinking described by Parnas in 1985 persists, even though much new development is based on a data paradigm and even though most people claim to be doing object-oriented programming. Developers thinking patterns, their mental habits, have not changed. Programmers, and software developers in general, still attempt to think like a computer.

Note  

Many readers will be familiar with most of the eminent scholars and practitioners cited in this book but not necessarily all of them. From time to time, it will be useful to introduce these authorities and provide some background regarding their accomplishments, confirming that their insights do indeed contribute to the issues at hand. Behind the Quotes will be a continuing sidebar used for this purpose.

Behind the Quotes ”Dr. David Lorge Parnas

Dr. David Lorge Parnas, P. Eng., Ph.D., Dr. h.c., FRSC, FACM, Dr. h.c., Director of the Software Engineering Programme, Department of Computing and Software, McMaster University, is the Director of the Software Engineering Programme in the Faculty of Engineering's Computing and Software Department. He has also held nonacademic positions advising Philips Computer Industry (Apeldoorn), the United States Naval Research Laboratory in Washington, D.C., and the IBM Federal Systems Division. The author of more than 200 papers and reports , Dr. Parnas is interested in most aspects of computer system design. Dr. Parnas won an Association for Computing Machinery (ACM) Best Paper Award in 1979 and two Most Influential Paper awards from the International Conference on Software Engineering. He is the 1998 winner of ACM SIGSOFT's Outstanding Research Award. Dr. Parnas is a Fellow of the Royal Society of Canada and a Fellow of the Association for Computing Machinery. He is licensed as a professional engineer in the province of Ontario, Canada.

Dr. Parnas was selected to head the software portion of the Strategic Defense Initiative (President Ronald Reagan s program to develop a missile defense system, commonly known as Star Wars ) ”a project from which he resigned when he and the other assembled experts concluded the software could not be written and tested . The quote used here is from a paper he wrote analyzing the problem and the abilities of software developers to address that problem. That paper was part of the public explanation of his resignation .

Few individuals can match the stature earned by Dr. Parnas in the realm of software development. Fewer still can match his moral conviction and willingness to uphold principle over mercenary considerations.

 

Now, it might be argued that the computer itself has changed substantially since 1985 such that the thing we are trying to think like is substantially different. We can investigate this claim by looking at programming languages. A programming language represents a virtual machine. Therefore, wouldn t an object-oriented language such as Java represent a very different kind of computer? If we think in Java, don t we think like objects instead of engaging in the kind of computerthink discussed by Parnas? Unfortunately, no. As we will see in Chapter 2, programming languages are shaped by their own set of presuppositions . Although you can implement object thinking in any programming language, knowing an OO language is not sufficient to engender object thinking. In Chapter 3, an example is presented that shows just how easy it is to replicate traditional thinking in a pure object language such as Smalltalk. Languages such as Java and object-modeling tools such as UML effectively define an object as the encapsulation of data structures and algorithms. According to this kind of definition, an object (as discussed previously in this chapter) is nothing more than a very tiny COBOL program. A COBOL program is the encapsulation of data structures (data division) and algorithms that operate on those data structures (procedure division). (In fact, creating object-oriented COBOL was a relatively simple task involving making the program smaller in scope and increasing the power of the interface division to make it easier for one COBOL program to interact with others.) This example shows that developers tend to perpetuate old thinking habits, albeit sometimes to a lesser degree.

It s useful to generalize Parnas s observation to accommodate datacentric development and development in nonprocedural languages such as Prolog and Lisp. The essence of thinking like a computer is thinking in terms of the means of problem solution. You view every development problem through the lens of the means you intend to use to solve that problem. In datacentric development, the means of solution consists of relations and relationships; for Prolog and LISP, a set of propositions or state declarations.

The generalization being made here is a variant of the adage, If your only tool is a hammer , every problem looks like a nail. Following Parnas, I m suggesting that software development has been distorted and that all the problems noted by Parnas persist because our only tool is a computer, so every problem looks like a virtual machine.

So, what is the object difference? How is thinking like an object different from thinking like a computer? Throughout this book, I ll be working to provide a complete answer to this question, but I ll preview a couple of differences here:

• Object thinking involves a very different means of solution ”a cooperating community of virtual persons . A virtual person is an entity capable of performing certain tasks. It has access to all the knowledge and resources required to complete its assigned tasks . Both virtual persons and virtual machines (computers) are really metaphors for how we think about problem solution ”but they are very different metaphors.

• Object thinking focuses our attention on the problem space rather than the solution space. Object thinkers take the advice of Plato, Parnas, Fred Brooks, Christopher Alexander, and many others by letting the problem define its own solution.

^[5] Parnas, David Lorge. Software Aspects of Strategic Defense Systems. American Scientist 73 (1985). pp. 432 “440.