Wednesday, April 9, 2008

What's an object anyway?

In his interesting post a year ago (Objects, I know that already), Paul discussed objects. Back when I studied for my computer science degree, we were taught about the object oriented paradigm - yet I feel quite strongly that some things cannot be understood by classroom teaching alone. My journey has been one of apprentice and I find that most good people I have worked with over the years, also have a level of humility that accepts that we must always be willing to learn from others.

So I see myself as disadvantaged, because I didn't begin to understand them until years later. Exposure to Smalltalk may have helped. In Smalltalk, everything is an object, messages are sent to objects, promoting loose coupling, in fact any message can be sent to a target object, and its up to the object to decide, at runtime, whether or not it understands how to handle the message. This subtle change in the thought process has a profound effect. Viewing an object from the outside as a consumer, allow us focus on things in a different way.

So back to classes and objects. Classes should be defined to represent things that relate to your problem domain. So a class of object used for one project could be completely different to a class of the same name used in a different project - it depends on context.

Classes provide us with services - image a service that can be consumed that's provided by a third party - you don't know how it works. In fact I try to apply the same thinking when I put classes together, I don't want to know how it works and it should be self contained and when I ask to use its services, I don't want to have to change the way I use it, if the class should change internally. This property is called encapsulation.

Hierarchies of classes can be put together based on an OO property - inheritance. This enables us to send a message to similar objects (as long as they are part of the same hierarchy) and the response could be radically different depending on it type. This is a powerful technique. Image a collection of graphical entities that you want to render on a page. As long as they are all members of a parent class PageComponent, you can send each item in the collection the 'render' message and each item will duly render itself.

Some years ago, a friend told me the real power of OO is delegation, not inheritance (thanks Rob). On a practical level, this means do only one thing well in a class and for anything else, delegate to other classes. Following this idea will lead to simpler code that is easier to read and understand, is less likely to go wrong, easier to maintain, more loosely coupled and easier to extend. For me, simplicity means everything. Ironically, it takes more commitment and effort to get there - but its worth it.

There is no magic to beginning to understand the usefulness objects - the more you work with them the higher the chance you'll start to understand. It took me years to get to a level of understanding (and I'm still learning) but it was definitely worth it. For you, it might take weeks - if you're really blessed with genius. One of the simplest pieces of advice I can offer is simply to think. Think about what an object should do, be responsible for - use a technique such as CRC cards and try to work with team members who have a level of understanding. Never stop learning.

There are a number of code smells associated with the misunderstanding of objects. Watch out for lots of setters and getters, big classes, having several responsibilities and a lack of collaboration with other classes. Always look at built in types with suspicion, this may indicate breaking encapsulation.

Don't look to OO as a panacea for anything, and as ever, what you get out of it, is only as good as what you put in. However, all things being equal it -

Can help understand the problem domain and can be a useful communication mechanism
Can help classify things in the problem so that we can deal with similar things in similar ways
Encourage thinking in terms of very small loosely coupled parts

In conclusion, I guess I am from the old school - the shopping list of skills I see on resumes these days counts for very little to me. I am far more concerned with depth of understanding of objects and other solid development practices than with current skill trends. The real benefits that can be gained from objects are only realized by the thought process of the diligent programmer who has an understanding of objects.

1 comment:

Paul said...

Hi Andrew,

I was lost about objects for years until I tried Smalltalk. In the end it turned out that what I thought objects were about initially was a lot closer to the truth then what you are lead to believe with C++.

The other big misleading thing for me was a book by Grady Booch: "Object Orientated Analysis and Designs with Applications"

It was all the rage at the time (1991), a bit like Gamma et al Design Patterns. It was THE book if you wanted to understand OO. Looking back now, I don't think Booch understood OO himself, choosing to focus on classes and inheritance rather than actual objects and messages.

The actual idea behind objects is very simple. But like so often in our industry people want to make things very complex. Smalltalk pulls back all that complexity and leaves you with Pure Objects and nothing but pure Objects.

With this degree of uniformity Objects become child's play. Smalltalk was designed for children :)