How I remembered Object Thinking

A revelation inside another revelation

I’ve been reading Object Thinking. It’s an unusual book, in that it talks mainly about the philosophy of OOP rather than technicalities like Dependency Injection. There are many gems in this book. One of the main things I got out of it is that Object Thinking is a revolutionary break with respect to established software engineering practice. Another thing is that the view of objects as Abstract Data Type is basically the establishment’s way to dilute and incorporate the grand new thing and make it look like a variation of the old thing.

Again, one thing that I changed my mind about is to take seriously the idea of modeling the domain. I mean, the old OOP books all said things like “take the description of your problem, underline the nouns in the description, and these are your candidate objects”. I used to think that this is a silly exercise! And I’m not alone. I heard many times the phrase: “objects are good, but not for the domain.”

In the last few years since I attended Francesco Cirillo‘s workshop on Emergent Design in 2009, I have been studying OOP. I learned about the GOF patterns. I learned about the SOLID principles. I learned how to write testable code. I learned how to do TDD for the infrastructure. I learned how to test-drive Chicago style and London style. I invented exercises for teaching the Hexagonal Architecture and the Open/Closed principle.

All of these things are good, and very useful to learn. Yet they are not the heart of Object Thinking. All these things are based on the shape of programs. For instance: I write a Long Method (bad), then I Extract Method a few times, then I Extract Class, and voila, I have done an Object Decomposition. But this is a mechanical exercise, that takes into account mostly the shape of the methods and not their meaning. If I’m lucky, my decomposed class will turn out to be something significant in terms of the domain. If I’m less lucky, I’ll have extracted some boring bit of infrastructure, like the IndoorSessionInitializer.

What I was missing on is decomposition based on Object Thinking. Decomposition based on writing the Domain Model. Thinking about the Domain Model as a simulation of the problem domain, as if the domain objects were little computer people sending messages to each other. Ding!

The incredible compressing brain of Kent Beck

Kent Beck’s brain contains probably the most efficient compression algorithm ever. Kent is able to compress in a couple of lines what others do take volumes to explain. Take Kent Beck’s four rules of simple design:

The right design for the software at any given time is the one that

  1. Runs all the tests.
  2. Has no duplicated logic. […]
  3. States every intention important to the programmers.
  4. Has the fewest possible classes and methods.

Kent Beck, Extreme Programming Explained

Consider item 2. It basically means: look at the shape of your code, and wherever you see the same information encoded twice, find a way to generalize or abstract so that it is encoded just once. In a few words he is implying the contents of the Refactoring book, of SOLID, and all approaches that look at the shape of code for guidance on how to improve its design.

Then consider item 3. It basically means: look at the meaning of your code, and make sure that the meaning is apparent in the names and the structure. This implies that you should make your code a model of the problem domain.

(Items 1 and 4 are just safeguards against making refactorings that break functionality, or going wild with OOD ideas and making the design worse by making it overcomplicated.)

Am I crazy or…

As an aside, I find myself buying lots of out-of-print books. It seems the things that I find most interesting are not what the world of programming in general finds interesting. Even my beloved Extreme Programming seems out of fashion lately. Nobody wrote about XP since Kent Beck wrote the last of the Coloured Books in 2004. But I still think that OOP and evolutionary design and XP are crucial things to learn. Yet everyone wants to learn about the latest technology fad. The latest technology fad I’m getting into is SmallTalk, and it’s something that stopped being developed around 1980. This means that either I’m crazy, or everyone else is.

In conclusion

When I was young I really believed in objects. My first falling in love with objects was over the cover of an issue of Byte Magazine dedicated to OOP.

I remember now that in nineteen-eighty-something I wrote an object-oriented program for an AI assignment. It was a program for symbolic integration that took inspiration from some crazy idea by Douglas Hofstadter. It was a community of software agents, each one specialized in some symbolic solution technique, that worked at the problem without any central coordination. It was written in some variant of Lisp that had no Object-Oriented extensions; so I wrote my own OOP system on top of Lisp. It was fun :-) and it was not difficult at all to do.

Then, in the nineties, I got enamored of formalist thinking; not the brand that did UML, but the brand that did Formal Methods. By then, OOP seemed such a scruffy and ineffective thing to me. But by that time, when I thought of OOP I was thinking of C++; I was thinking of large, unwieldy frameworks based on very long inheritance chains. Small wonder that I didn’t like it.

In the eighties, when I thought of objects, I thought of letting artificial intelligence emerge out of the collaboration of many simple autonomous agents. What a silly and romantic idea! Yet this idea is at the heart of OOP as was originally imagined by Alan Kay and the others.

This is probably a good place to comment on the difference between what we thought of as OOP-style and the superficial encapsulation called “abstract data types” that was just starting to be investigated in academic circles. … To put it mildly, we were quite amazed at this, since to us, what Simula had whispered was something much stronger than simply reimplementing a weak and ad hoc idea. What I got from Simula was that you could now replace bindings and assignment with goals. … the objects should be presented as sites of higher level behaviors more appropriate for use as dynamic components.
Alan Kay, The Early History of SmallTalk

5 Responses to “How I remembered Object Thinking”

  1. Carlo Garatti Says:

    Great Matteo, i reach the same results without have your experience. In my opinion the key is A NEW WAY OF THINKING, a NEW mindset. the collaboration diagram of the cirillo’s workshop is not only a WAY for learn to think :D?

  2. Moreno Carullo Says:

    Great post, Matteo.

    I agree 99.99% — the fundamentals of OOAD are certainly far more useful than any technology-specific stuff.

    On the Smalltalk side, I also started toying with it (you know, Davide?) and a new world opened to me. But when you see a young guy like Avy Bryant releasing great stuff like Seaside, how can you say that Smalltalk development ended in the 80s? :-) (yes, this is the 0.01% bit missing!)

    — Moreno

  3. matteo Says:

    Seaside is certainly great stuff (even though it goes straight against my intuition about how web applications should work!) But I said that *SmallTalk* itself stopped evolving in 1980. If I’m not mistaken (I don’t know for sure) Squeak and Pharo are essentially reimplementation of the same language.

    Alan Kay himself says, in his OOPSLA video The Computer Revolution Hasn’t Started Yet, that from 1970 to 1980 SmallTalk was reinvented every two years, but when they published SmallTalk-80 to the world, everyone thought “hey, this is SmallTalk, let’s learn it” rather than “let’s reinvent it” !

    For instance, one fun thing Kay mentions in the Early History of SmallTalk is that he likes that in Prolog, even variables are objects that exhibit specific behaviours. This is a sample of what he means when he says that a key ingredient of OO is having access to meta-levels all the way through!

  4. Jacopo Says:

    “[..] It was a community of software agents, each one specialized in some symbolic solution technique, that worked at the problem without any central coordination [..]”

    Here it comes a funny story.

    I was wearing my “Anti-IF campaign” shirt (the one from Cirillo), and a friend of mine just asked “why polymorphism?” (stated on the back of the shirt). she studies chemistry and biology, so she was wondering if “my polymorphism” was related in any way with “her polymorphosm”: a property of cells, which can potentially act in many ways.

    And the answer is: yes!

    “[..] It’s object-oriented programming. [..] I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages [..]”

    — Dr. Alan Kay on the Meaning of “Object-Oriented Programming” (


  5. Uberto Says:

    Well I think all the DDD movement is the best place to discuss how to map OO on domain.
    I also disagree with the recipe: “take the description of your problem, underline the nouns in the description, and these are your candidate objects”
    I tried in the past and the result were orrible distribuited logic and god classes.
    We need a maieutic approach in extracting objects from specification as Evans said.

Leave a Reply