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!

no subject

I realise I forgot to talk about what methods are in this post. I'll edit the post a bit later to add the information, though right now I'm a bit tired.

Very simply, though: Methods are code routines that an object can have, which can interact with the memory store of that object. For example, a door might have "open" and "close" methods, which changes whether the door is opened or closed, and a book might have a "nextPage" method, which flips to the next page. (And the RTLBook class would probably have its own "nextPage" method.)

no subject

I'll be honest, even I'm not sure what polymorphism is. My goal here isn't to explain everything about OO, but rather how OO relates to the DW codebase. The only really common case of multiple inheritance I know of in Perl OO is when you're inheriting from Exporter, but I mostly just treat that as magic rather than thinking of the actual things behind it. *grins*

no subject

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.

no subject

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".

no subject

no subject

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.

no subject

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.