sophie: A cartoon-like representation of a girl standing on a hill, with brown hair, blue eyes, a flowery top, and blue skirt. ☀ (Default)
Sophie ([personal profile] sophie) wrote in [site community profile] dw_dev_training2012-02-13 09:03 pm

DW object-oriented programming explained (Part 1)

The Dreamwidth codebase uses object-oriented programming a lot, or "OO" as it's known. But what exactly is OO? In this post I'm going to explain the concepts of OO. I plan this to be the first in a series; in later posts I'll explain how OO programming relates to the DW codebase, some gotchas that might arise, and other such things.

For now though, an introduction to the basic concepts of OO!

First, let's look at a real-life analogy. An "object" in real life can be just about anything; a book, a shampoo bottle, a door, etc. (Yes, I just looked around my room and used the first three objects that came to mind.) We know various things about the objects; a book has pages which can be turned, a shampoo bottle has a cap that can be opened, and a door can be opened to give access to something else, such as another room.

These aren't just specific to that object either. All the books in my house have pages, etc. That's because they were designed that way, probably from the same blueprint. (Or very similar ones, but I'll get into that in a bit.) The books themselves have different contents, but they were all designed the same way.

What I just described is the basics of how "classes" and "objects" work. A "class" is a blueprint for a type of object. It describes how the object works, but it doesn't describe what any particular object is for. An "object", on the other hand, is a tangible thing that has been constructed from the class. (Some people use the word "instantiated" instead of "constructed", but it means the same thing.)

Returning to our real-world examples, there are things that are going to be different about each book, even it they're constructed from the same blueprint - the actual content is an obvious example. Another example is the number of pages in each book.

The same is true in OO objects. Each object can have its own memory store, where information about that particular object is held. (Each piece of information is normally called a "property"). The class dictates the layout of this memory store, but not the contents. For example, the "Book" class might allow for a "number_of_pages" property, but in each object the value of that property will be different.

Even though my books all have pages, some of my books - mostly manga - are meant to be read right-to-left, so the book pages flip the opposite way to most of my other books. It's not quite the same as a book that reads left-to-right, so it's not quite from the same blueprint, but that's really the only major difference from most of my books.

Here's where the real world and OO world differ slightly. In the real world you'd need to make a whole new blueprint that repeats the same information for a type of book that flips from right to left. In OO, however, when you make a new class (let's call it "RTLBook", for 'right-to-left book'), you can say that the new class should 'inherit' from another class (such as the Book class), meaning that everything that holds true for the Book class also holds true for the RTLBook class, except for the bits for which you specifically say otherwise. I can then say that any objects constructed from the RTLBook class should have pages that flip from right to left instead of left to right.

This means that if I change anything in the Book class - say, if I added a property for the colour of the pages - the RTLBook class will get the same changes, as long as it doesn't relate to the way the pages flip. So it not only saves on typing, but it also makes code maintenance easier!

And that, in a nutshell, is what OO is all about. In the next post on this subject - which may be in a few days or a week, I don't know yet - I'll be talking about how this applies to the Dreamwidth codebase. :)

If anybody has any questions so far about what I've said in this post, please feel free to comment!
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)

[staff profile] mark 2012-02-13 09:23 pm (UTC)(link)
This is great!

(Also, I look forward to when you get to multiple inheritance and polymorphism. And other similar OO concepts that are just... you did what to the who now?)
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)

[staff profile] mark 2012-02-13 10:34 pm (UTC)(link)
It means many things, but commonly, polymorphism is just a fancy way of saying that an object satisfies several classes. This is most useful in the situation where you have, say,

class MyBase;
implements Foo, Bar;

class MyRealClass inherits from MyBase;
implements Foo;

class MyOtherClass inherits from MyBase;
implements Bar;

Elsewhere, you can say that something takes a MyBase and in reality, someone can pass it a MyRealClass. For the purpose of that function, you treat MyRealClass as MyBase... it is polymorphic. I.e., has several forms. But when you call Foo on it, it's actually calling MyRealClass::Foo, not MyBase::Foo. Even though the function in question doesn't know what a MyRealClass is.

(This is an example of late/dynamic binding, an implementation of polymorphism, -- read more at http://en.wikipedia.org/wiki/Dynamic_binding_(computer_science) if you're curious. But in reality, it can mean other things, too. The word itself is polymorphic! Augh!)
tcpip: (Default)

[personal profile] tcpip 2012-02-14 04:34 am (UTC)(link)
Polymorphism means that Objects can respond differently to the same message by distinguishing between implementation from behaviour.

Consider for example (vaguely related to our book example), the message "print". That's a behaviour. But for (say) an accounts object that means "print to PDF", whereas for a contract object that means "print to LaserJet1".

Does that make it a little clearer?
extends: (a thoughtful smile)

[personal profile] extends 2012-02-13 11:50 pm (UTC)(link)
Awesome explanation! And more colloquial than what I got in my Java classes hahaha.
heavenlyevil: Painting of a fairy croched menacingly on a flower. (Default)

[personal profile] heavenlyevil 2012-02-14 01:42 am (UTC)(link)
I love this! I've been wanting to learn more programming than the lame ColdFusion stuff I had in school, and though I can cobble together php scripts they are surely crap because I don't know what I'm doing.

This series should help immensely with that whole learning-Perl-to-work-on-DW plan I've got percolating.
azurelunatic: Azz and best friend grabbing each other's noses.  (Default)

[personal profile] azurelunatic 2012-02-15 06:14 am (UTC)(link)
If you happen to get hung up at any particular point, do feel free to shout out! This is the sort of thing where lots of people may be able to be helpful, and bystanders may wind up picking up something to help with something they were stuck on.