Part One – OOP The Easy Way

What is object-oriented programming? My guess is that object-oriented programming will be in the 1980’s what structured programming was in the 1970’s. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is.

Tim Rentsch, Object oriented programming—https://dl.acm.org/citation.cfm?id=947961

Object-Oriented Programming (OOP) has its beginnings in the simulation-focused features of the Simula programming language but was famously developed and evangelized by the Smalltalk team at Xerox’s Palo Alto Research Center. They designed a computing system intended to be personal, with a programming environment accessible to children who could learn about the world and about the computer simultaneously by modeling real-world problems on their computer.

I recently researched the propagation and extension of OOP from PARC to the wider software engineering community, which formed the background to my dissertation We Need to (Small)Talk: object-oriented programming with graphical code browsers—https://www.academia.edu/34882629/We_need_to_Small_talk_object-oriented_programming_with_graphical_code_browsers. What I found confused me: how had this simple design language for children to construct computer programs become so complicated and troublesome that professional software engineers struggled to understand it before declaring it a failure and reaching for other paradigms?

A textbook on my shelf, “A Touch of Class,” by Bertrand Meyer, claims to be “a revolutionary introductory programming textbook that makes learning programming fun and rewarding.” At 876 pages, it makes it a good workout, too: not for the schoolchild, but for the “entering-computer-science student” at degree level.

Digging further showed that the field of object thinking, object technology, OOP, or whatever you would like to call it had been subject to two forces:

• Additive complexity. Consultants, academics, and architects keen to make their mark on the world had extended basic underlying ideas to provide their own, unique, marketable contributions. While potentially valuable in isolation, the aggregation of these additions (and they were, as we shall see, deliberately aggregated in some cases) yields a rat’s nest of complexity.
• Structured on-ramps. To make OOP appear easier and more accessible, people developed “object-oriented” extensions to existing programming tools and processes. While this made it easy to access the observable features of OOP, it made it ironically more difficult to access the mental shift needed to take full advantage of what is fundamentally a thought process and problem-solving technique. By fitting the object model into existing systems, technologists doomed it to stay within existing mindsets.

About the Example Code

In this part of the book, I have consciously chosen to use “mainstream,” popular programming languages wherever possible. I have not stuck to any one language, but have used things that most experienced programmers should be able to understand at a glance: Ruby, Python, and JavaScript will be common. Where I’ve used other languages, I’ve done so to express a particular historical context (Smalltalk, Erlang, and Eiffel will be prevalent here) or to show ideas from certain communities (Haskell or Lisp).

One of the points of this part of the book is that as a cognitive tool, OOP is not specific to any programming language, and indeed many of the languages that are billed as object-oriented languages make what (or at least large parts of what) harder. Picking any one language for the sample code would then mean only presenting a subset of OOP.