Peak Objects

I was aware of a need for object-oriented programming long before I learned that it existed. I felt the need because I was using C and Lisp to build mediumsized systems, including a widely-used text editor, CASE and VLSI tools. Stated simply, I wanted flexible connections between providers and consumers of behavior in my systems. For example, in the text editor anything could produce text (files, in-memory buffers, selections, output of formatters, etc) and be connected to any consumer of text. Object-oriented programming solved this problem, and many others; it also provided a clearer way to think about the problems. For me, this thinking was very pragmatic: object solved practical programming problems cleanly. The philosophical viewpoint that “objects model the real world” has never appealed to me. There are many computational models, including functions, objects, algebras, processes, constraints, rules, automata – and each has a particular ability to model interesting phenomena. While some objects model some aspects of the real world, I do not believe they are inherently better suited to this task than other approaches. Considered another way, what percentage of classes in the implementation of a program have any analog in the real world? In the mid-’80s, when I was learning about objects, it was frequently said that objects could not be explained, they must be experienced. Sufficient experience would lead to an “Ah ha!” insight after which you could smile knowingly and say “it can’t be explained... it must be experienced.” This is, unfortunately, still true to a degree. Many students (and programmers) do not feel comfortable with dynamic dispatch, the higher-order nature of objects and factories, or complex subtype/inheritance hierarchies. Advanced programmers also struggle to design effective architectures using advanced techniques – where the best approach is not obvious. In what follows I describe some long-standing myths about object-oriented programming and then suggest future directions.