[1+1=2]

OneAndOneIs2

« My so-called standoffish kittenNew Year's Resolutions »

Sun, Jan 16, 2011

[Icon][Icon]What *is* OOP?

• Post categories: Omni, Technology, My Life, Programming

So I've played around with Python, and then with PHP, and now Perl. All three can be used for object-oriented programming.

A while ago, when I was trying to learn more PHP, I started to feel the lack of knowledge about its OOP aspect. Having started out with K&R's book on C, procedural logic has always made sense to me: What was this object thing?

So I googled around for a while, and what I basically came up with was.. nothing. Not a thing. No matter how I looked, I could never find a clear, simple explanation of just what object-oriented programming IS.

So I thought I might have a go at explaining it myself.


Executive summary: Objects are just variables that can process data as well as store it.

To expand: Let's imagine a vet who wants to upgrade from paper records to a computer system. This involves writing some code to handle record-keeping.

So, we sit down and write some code. Naturally, the code needs to be able to handle data, and we store this in variables: Essentially, this is just a name given to a place in the computer's memory where data can be stored.

So we start out simply: What do our records need? Well, we want to store the animal's name, its species, it's date of birth, and its owner's details.

In our program, we therefore have $pet_name, $owner_name, $pet_dob, and $pet_species.

And that works fine. Except that, as the codebase gets larger and larger, having all these separate variable names gets to be a bit of a headache. Not only is it a lot of typing, but sometimes you can forget to update one variable when you update others, giving results such as a parrot named Fido and a pitbull named Mittens. And sometimes we want to have TWO animals' details loaded at once, and then we have to duplicate all those variable names for animal 1 and animal 2.

It would be nice if we could have one single record with *all* the data in it, and eliminate all these problems.

Enter the array: A single variable that can hold multiple values, in a nice orderly list. We replace the multiple independent variables $pet_name, $owner_name, $pet_dob, and $pet_species with a single array. Pet name is now $pet[0], owner name is $pet[1], birthdate is $pet[2] and species is $pet[3]

Beautiful and simple, and this works okay for a while. But time goes by and those numbers start to get hard to remember when we come back to the code after a break: Sometimes we use the wrong number and start sending emails to Mr. Dog regarding Benji, his pet seventh of July.

So we want something a bit more meaningful than a number to access our information, and this is where the hash table comes into play. Like an array, it's a single variable that can hold multiple pieces of data. But unlike an array, it is unordered, and data is accessed by name instead of number.

We update the codebase, and now we have $pet{name}, $pet{owner}, $pet{dob}, and $pet{species}. And that's all wonderful and does everything we need.

But as the code grows ever bigger, we start to find a lot of replication in our code - redundancies abound as the same calculations have to be done in multiple places. Our main problem is the pet's age: This obviously can't be stored as a number on the database, because it's not a static number. But we need to call it in multiple places: Vaccinations, neutering, routine checkups, etc. etc. It would be nice if the pet's age could be accessed via the variable, instead of having to get the age and then work out the age each time it's needed.

Enter the object. Like our other variables, this can store data. But it can also have methods assigned to it. So we replace our pet hash tables with pet objects, and now we have $pet->name, $pet->owner, $pet->dob, and $pet->species - methods that do nothing but get or set the data. But we also set up $pet->age, a method that subtracts the pet date of birth from today's date and so returns the correct age.

The beauty of the object concept is that it abstracts processes: $pet->dob just gets information from the database, whereas $pet->age performs a calculation to return dynamic data. But both are called in the same way, and you don't ever have to care about where the data comes from or what's done to it: It's just data that you call when you need it.

What's more, objects can inherit their definitions from one or more other types of object. Let's say that you have four types of animal: Cat, dog, bird, and reptile. Every single one of them is a pet, and they will all have owners, a date of birth, a name, and a species. Great. We have data fields set up for those in $pet

But cats and dogs need vaccinations and boosters, whereas reptiles and birds don't. So we set up four new types of object, or "class". But we don't have any redundant code, specifying repeatedly a $dog->dob, $cat->dob etc.

No, we just set all four classes to inherit from the $pet definition, and it all Just Works. We then add a few extra data types to $dog and $cat - neutered, vaccination_date, booster_date and fur_colour.

And that's great, but then we think actually, we should be keeping the animal's history in their records as well. So now, we can add previous_conditions to the $pet definition, which all four other classes inherit from, and instantly all four types are updated to have the new history field in them.

Then we think, hey, booster dates are calculated based on vaccination dates. So instead of booster_date being something that the vet works out in their head and then enters manually, let's change it to be a method that looks at vaccination_date and works out the right date on its own.

So we go ahead and do this. And because it's all abstracted into the object, we don't need to change *any* of the code that refers to the booster date: We needed to call $dog->booster_date when the date was manually entered into the database; we now need to call $dog->booster_date when it's calculating the date on the fly.

So, in summary:

  • A variable is a name for a piece of data
  • An array is a variable that holds multiple values
  • A hash table is a variable that holds multiple values accessed by name
  • An object is a variable that holds multiple values that can be either static or dynamically-generated

It's worth knowing that objects can inherit from other objects, and that methods are abstracted away from the code, and all that. Of course it is. But it's only worth knowing all that when you've already got an answer to what an object *is* in the first place.

When other people have sat down and written guides to OOP, they've thought "What do people need to know?" and so they've thrown out terms like inheritance, polymorphism, and god knows what else. I've tried to approach it from the other side, and hopefully it's made some sense.

Feedback is always welcome..


6 comments

pdh
Comment from: pdh [Visitor]
My two cents is that you missed a few key concepts... but in essence the example works reasonably well.. the animal kingdom is a classic and isn't so far off wikipedia's article on it (which I find a little easier to follow).

Surprised you didn't find any articles nicely defining it, there are a good few out there... Although oddly I think my lecture notes are the best ones I have still :)
16/01/11 @ 20:04
oneandoneis2
Comment from: oneandoneis2 [Member] · http://geekblog.oneandoneis2.org/
All the articles I came across were like.. well, imagine somebody trying to explain what a car is to somebody from five hundred years ago like this:

"Right, well it's got an engine - I'll tell you what that is later - that usually is at the front, but can be in the middle or sometimes goes at the back. The engine uses petrol - we'll come back to that later - for power. There's usually five, but sometimes only two and on others seven or eight, seats. It's usually made out of metal, but plastic - I'll tell you about that later, it's related to petrol - remember me saying I'd tell you about petrol later? Anyway, plastic's getting quite a lot of use these days."

That's what most OOP articles come across like - they're so keen to rave about polymorphism and how much more like real-world objects the code is, they never sit down and start with the equivalent of "A car is a vehicle with four wheels that moves under its own power"

They want to start talking about polymorphism and inheritance and classes and methods, and never just stop and say "This is what an object IS:"

I never found anything that did that, so I wrote one.

And yeah, I left stuff out - it's supposed to be a basic intro to the concept, not an in-depth guide :P
17/01/11 @ 12:44
herd
Comment from: herd [Visitor]
Or just view it as if you were a C-programmer that dives into C++:

- You know what a 'struct' is.
- You know what a pointer is.
- You know what function pointer is.

So a C++ object is a C struct with a bunch of function pointers to function bodies that operate on the other variable members of the same struct. How do they know which struct instance to work on? Those functions that are not declared 'static' carry a hidden 'this' pointer as their first argument, that just contains a pointer to the struct instance.

Plus some syntactic sugar to make the compiler more pedantic like 'private', 'protected' etc.

With this way of thinking, a humble C programmer can grasp the whereabouts of OOP and even implement them, that's how GTK+ became object oriented even though its written in good old C.
17/01/11 @ 17:17
Irfan
Comment from: Irfan [Visitor]
Very nice article and corresponding comments. Would appreciate if some further web links/resources are also mentioned.
Thank you all.
22/01/11 @ 15:55
pdh
Comment from: pdh [Visitor]
@Ifran,

Check these links for *basic starters*.
(php oop)
http://programmersnotes.info/2009/02/28/what-is-oop-object-oriented-programming/
(chapter on oop in c)
http://www.polberger.se/components/read/demystifying-dynamic-dispatch-wikipedia.html
(perl oop)
http://www.troubleshooters.com/codecorn/littperl/perloop.htm
23/01/11 @ 07:56
Irfan
Comment from: Irfan [Visitor]
Thank you, I appreciate.
10/02/11 @ 14:43
 

[Links][icon] My links

[Icon][Icon]About Me

[Icon][Icon]About this blog

[Icon][Icon]My /. profile

[Icon][Icon]My Wishlist

[Icon]MyCommerce

[FSF Associate Member]


December 2017
Mon Tue Wed Thu Fri Sat Sun
 << <   > >>
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Search

User tools

XML Feeds

eXTReMe Tracker

Valid XHTML 1.0 Transitional

Valid CSS!

[Valid RSS feed]

blog software