Friday, September 4, 2009

Objects 101

I have heard some interesting stories recently and am beginning to comprehend where my assumptions are going awry. My time spent in academia included lecture theatre discussions about the object oriented paradigm any why many believed it was a major step forward. Yes I am going back in time a little here, but in my opinion, objects are still a very powerful way to understand both the problem and solution domains and I very much believe in them - until something better comes along. Having said all that - I am interested in functional languages as well - although I’m not sure that they have to be classified under a completely different paradigm.

It has only recently struck me how fortunate I have been to have worked with many talented people. My ‘apprenticeship’, under the wing some very experienced mentors, provided me with a solid grounding and a varied toolbox of techniques, approaches and strategies for delivering software – but the more experienced I become, the more I realize I have to learn.

Object technology is one of the most misunderstood concepts in computer science, while simultaneously one of the most simplistic. There are really very few key ideas behind them, but it is a subject that will only become apparent to open minded developers over time. I do not claim to be an object expert, just open minded enough to keep learning about them. Part of the problem is unlearning the procedural habits of the past, most modern languages apparently encourage that way of thinking.

1. Objects have the great property that they try to model things of interest in the real world. As such, they can be used to model the problem domain (forget about computers for a minute) as well as the solution domain. Use objects to understand the problem domain first. Get up to the white board and ask your customer about the key abstractions in the problem domain and their relationships to one another
2. Their key advantage lies in their ability to break down complexity and talk to one another to get the job done. When an object talks to another, it sends a message – if the receiving object understands the message, it selects an appropriate method to execute and sends the answer back to the caller. The caller does not need to understand what is going on though, only that the message it has sent gets a response.
3. You can speak to a number objects in the same way, e.g. if you have a number of sprite objects that all require drawing, you don’t have to know which is which, you can just send them all the ‘Draw’ message and if they respond to the same protocol, they will do as asked. This is usually achieved by inheritance or interfaces in most statically typed languages.
4. Objects should focus their efforts on doing on thing well – if you find an object doing a calculation, formatting some text and rendering some shapes on a screen, its doing too much.

A number of enlightening books on the subject have on the subject from the last 30 years contain more than enough information to make most developers’ lives far less complicated. In my experience, the majority of issues developers face are man-made and using objects sensibly can go a long way to minimizing this ‘accidental’ complexity. I have heard it said that the promise of object technology didn’t deliver – in reality, it never had a chance in a world where many didn’t seek to understand and influential organizations downplay it for financial advantage.

It seems as if the diligent use of the OO paradigm is regressing, perhaps to be viewed as a fad, while we slip further into a dark and distant procedural past.

2 comments:

Cory Wheeler said...

Hi Andrew,

I was reading a post by Michael Feathers, 10 Papers Every Programmer Should Read (At Least Twice)... http://tinyurl.com/ab3tgn , which lead me to reading an old article put out by Kent Beck and Ward Cunningham, A Laboratory For Teaching Object-Oriented Thinking... http://tinyurl.com/5898f9 , in which they discuss CRC cards.

Several of the themes put forth by you are also stated there, the first of which that lept out at me is the need to relinquish the procedural programming mindset. You make the statements that most modern languages seemingly encourage that way of thinking and that the diligent use of the OO paradigm is regressing. For our industry, I sincerely hope that is not the case as I believe that would truly be a regression... not progression.

As I've not used CRC cards before, after reading this article I do intend to use them in some fashion, even if it is just as an exercise on a personal project...twittling away in my basement next to my 40-Watt light bulb, as it looks like great, simple, physical modeling manifestation of the logical problem you are trying to solve when building software.

Hope all is well... and take care,
Cory Wheeler

Andrew Walker said...

Cory, yes that is an interesting paper. I tought a 'CRC cards' class in London about 15 years ago and at the time everyone found it very insightful. It does make for a useful learning tool.