12 January 2006
Thinking about objects
I was doing something completely unrelated to this topic when for some reason I thought of a nice way to explain object orientated programming in an easy to understand way (by the way I should say the book that made it click for me was Stephen Kochans’ Programming in Objective-C). Most arguments start out my coming up with some physical allegory to an object; an iPod class containing a artist and song names for example. But how about this ….
We programme to automate as task. That is to say that there is a sequence of steps that need to be completed to get to the end result. Say we are in a situation where we need to get a form signed by a number of different people. A way to do this would be to go to the first person in one building, then catch the bus over town to see the second person, then return back to campus to see your tutor for the third signature ad infinitum. This is the sequential paradigm of programming.
Another way would be rather than you working on the most basic level of moving this piece of (dare I say it, ‘data’) paper around. You could work on a more abstract level. You could turn your form into a an object – put in in an evelope and turn it into a letter! Everybody knows how to interface with a letter, but not everybody knows how to deal with that specific implementations required by piece of paper that we had before this is why it’s an abstraction.
What are the salient features of a letter? It encapsulates some information, my form. We are only allowed to open it if we are the receiver of the letter.
Back to the story.
So how do we get our letter to it’s first recipient? We write a message on the front that tells the postman/woman where it need to go; in this case the address of the first recipient. Then we put it in the post box and we’re done! We have set forth a sequence of events that will accumulate in the letter getting to it’s target.
So as you can see because the Postman know how to deal with a letter, what used to be a linear sequence of events can get done without the nitty gritty of gragging the form from desk to desk.
Okay time to get real.
The form represents some data or our instance variables . For a form the data would most probably be my name, address, contact details etc. The envelope represents a class, that is, a blue print from which we can make a letter object. My letter (this is a difference between an envelope and a letter) is an instance of class envelope. The message is the address we write on the letter. It’s a message to Pat, (instance of class Postman!), because Pat is a Postman he understand how to turn this message into the action of the letter reaching it’s target. Once at the receiver desk he/she knows how do open (or interace with) a letter and can follow yet more messages contined in the encapsulated data and form that will make my form get from A to B to C ad infinitum.
So how could this look in a programme:
// import the knowledge of how to use a letter. This header file contain the interface details
#import “Envelope.h”
int main(int argc, char *argv[])
{
//make a ‘Form’ object and fill with details
//.
//.
//.
// we now have a form called ‘myForm’
//make an envelope into a letter i.e. instantiate a class.
Envelope *myLetter = [[Envelope alloc] init];
//fill the letter with information by sending it messages
[myLetter setAddress: @"42, Cocoa Road, Mutable Avenue"]
[myLetter setContents: myForm];
//put the letter in a post box or find a post man!
[postmanPat myLetter];
/*postmanPat is an instance of class Postman an understand how to use the method -address from the Envelope class*/
}