Sophie (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
sophie) wrote in ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
dw_dev_training2012-02-13 09:03 pm
sophie) wrote in dw_dev_training2012-02-13 09:03 pm
Entry tags:
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!
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