Back in the days when I was building equipment and processes they usually started with managers coming to me and presenting their concept of what they needed. From there I would break down the concept into their functional pieces and individual responsibilities.

Time and time again I decomposed concepts in this fashion and it truly became second nature to me. Each piece was tangible and each piece only has a small set of what you could do with it, and you couldn’t change it. of course you could always build a new item to extend the capabilities of several general items.

Moving forward, when I started working with “traditional” computer programs I took to OOP because it continued to feel right. I still continue to break down a concept into objects and let each of them handle the tasks I needed them too. I’ll admit though when it came to software I wasn’t decomposing into object well enough, or even realized what and why I was doing it.

I just completed reading Object Thinking by David West. For me it was one of those pivotal reads of my career. I’m not someone who can easily read and learn, I’m learner by doing, but Mr. West’s writing style made it easy for me to read Object Thinking and immediately pick up the ideas.

In Chapter 2 the philosophical context of Formalism and Hermeneutics was introduced, and subsequently used throughout the book.

Formalism in short is the belief in “logic and order”. “All that is bad in software arises from deviations from formal descriptions that use precisely defined tokens and syntactic rules.” (51) I’ve seen this belief in all the software projects I’ve worked on.

Hermeneutics is the belief that “the world is more usefully thought of as self-organizing, adaptive, and evolutionary with emergence properties.” (53) In software, new opportunities emerge that hermeneutics expect and understand will happen.

The comparison between formalistic and hermeneutics is only a small part of the book but sets the stage in understanding how to think like a object.

When thinking like an object you first need to understand the problem domain that you will decompose. Objects need to be fine grained by natural behaviors and responsibilities, if an object appears to have to much responsibility it can probably be seperated into other objects. Object need to be composible so they can be combined in many ways to form other composite objcets.

There are tools in order to help think like an object. Class-Responsibility-Collaborator cards as examples are used in the book. Each object is described on a simple 3×5 card noting only responsibilities of the object. Also included are any collaborator objects that are needed to help the object complete it’s function.

Yes that the intent of the small cards with limited space to assign responsibilities. Having to many responsibilities to assign means maybe the object needs to be redefined, or broken down into other objects. The cards are needed only during the definition phase to help us in our thinking.

When starting to work though, throw the cards and notes out. As Mr. West implies, when we can think like an object completely in our head while working we truly have Object Thinking.

When it came to object thinking in the mechanical world it was easy form me. All the fundamental objects were already built and I just needed to put them together correctly for the equipment. In software though this wasn’t necessarily true. While I still attempted to decompose the problem into objects but needed the help in understanding what I was doing.

It’s clear to me that only a week after finishing the book my programming has clearly taken a turn in a new direction. My class have become smaller and easier to maintain. I can also see the natural joins and when to split responsibilities into new classes. All in all Object Thinking is definitely a book on my desk for quick reference and not the bookshelf!

Tags: reading