Simple Object-oriented programming (OOP) concepts explanation

I don't include code samples because this should be used to understand the concepts rather than teach you to program. Please feel free to use it but please give me the credit if you use!

We start with 2 concepts

• A Class
• An Object also known as An Instance

So in object orientated programming, the structure has been built around the idea of the real world. So lets take it back to the real world for a second.
If I want to build a house what do I need? Okay before you say bricks, windows lets just make it a little less detailed and just say you need rooms.
OK so how do we make a room, erm... Well that's our first problem, we need a plan. So we draw up a blueprint of what our room is going to look like. For now we don't much care about what kind of room it is, we just need a room. So our blueprint defines 4 walls and a roof and a floor.
Great now we know how to build the room, how do we build it? Well get a builder so lets not worry to much about that part, let assume we can give someone the plans and they'll give us a room. Its good to note at this point that you can give the same plan to that builder or another builder over and over again and each time they'll give us back a similiar room.
So if our house is a collection of rooms we can make a whole house using the same plan a couple of times over to create a couple of rooms, put them together and whoala, we have a house. Albeit a very boring bare house.

So bringing the example above back to object orientation. We can say the blueprint is the class and the room is the object or instance of the room's blueprint.
The collection of rooms are just that, they can be grouped in either a collection (a instance of a collection blueprint or class) or an array which is just basically putting them side by side in your computers memory.

Now lets EXTEND on that!

OK so lets make out house a bit more interesting, shall we? We need a bathroom, with a toilet and a bath and a basin. Other than that it should be a room. So rather than start from scratch lets just staple some additional instructions to our builder onto the room blueprint.
So what do we want?

1. We want a room
2. We want a bathroom in the room
3. We want a sink in the room
4. We want a basin in the room

So what we are basically doing is EXTENDING our idea of a room. Which is the next concept in object orientation. You have something that's almost what you need, you tweak it, and whoala you have the new thing. Then we just give it to the builder with the extra notes and he makes us a bathroom room or kitchen, depending on the extended blueprint.

Lovely! So why not just copy and paste the class and give it another name, like make a bathroom blueprint from scratch. Well 4 reasons:

1. Cause you actually doing just that anyway, because you are going to make a new class, its just going to be extending the other class. Basically just steal all its functionality.
2. Because then its not a room anymore and we cannot refer to it as a room anymore. The nice thing about extending from a basic concept is that in code you can actually refer to the more complex items as their basic counterparts. For example I can still have a collection of rooms to my house, but now some of those rooms will just happen to be bath rooms. If we made a whole new bathroom blueprint it would be a different concept all together and we'd need to have 2 collections, one for all our normal rooms and one for our bathrooms, and that is just horribly inefficient.
   
3. Because sometimes, you don't have access to the code of the class you want to extend. There are heaps of libraries of classes scattered over the Internet which might all do almost what you want but not quite. But you won't always have access to their code. So you'd have to resort to EXTENDING them to get what you want.
4. And most importantly! Why do you want to take the risk of making a mistake recoding something that already works! Debugging takes up more time than coding in many scenarios so why go there?

In its simplest form most of the above benefits can be obtained by using an INTERFACE. Basically all an INTERFACE is, is a tick list of things to include. So if our room had an interface it would say something like, make sure its got walls a ceiling and a floor. It won't define any detail about the walls or the floor or the ceiling but it will just make sure its there. If our room had been using an interface we would have said it IMPLEMENTED the INTERFACE. Hey I'm a poet!
When the builder then took the room to his boss, the boss would get out his checklist and tick off
Walls. check!
Ceiling. check!
Floor???? Where is the floor?
And the builder would have to come back to you and say listen about your room, you forgot to add the floor and according to you tick list, or interface, it should have one. Could you please revise the blueprint and give it back to me?

We can cheat a little with the above scenario. Lets say our initial INTERFACE for a room stated that the room should always have a window. Sometimes however this isn't important to us, but its important enough in most cases that you want it in your check list or interface. So what we then do is we
first:

• Implement our interface and build a blueprint of a "standard" room, but instead of specifying all the details we just specify some defaults. So for the windows section we just say, "no windows", for the walls we say "no walls" for the floor we say "no floors" etc.

second

• We EXTEND our standard room, and make it into everything we want. But because the standard room blueprint already says "no windows". If we neglect to fill in anything about the windows on our new rooms blueprint. The builder won't be bothered because he can see the default is "no windows" so he'll assume that is what he needs to do.

Nice thing about this is we can refer to all our rooms by the name of the interface, lets say its called iRooms. So now we can build our house out of a collection of iRooms. Which can be anything as long as it ticks all the boxes. Cool huh?
Its good to mention here that Implementing an Interface, or Extending a Class does not limit you to their functionality. You can add whatever you want on top of whatever is there.

OK minor problem emerging here!

Lets say I take a room out of my house collection...., what kind of a room is it?

I don't know!

OK well I'm just going to the loo in it..... NOOOOOOOOOOO! Crash. (wanted to use another word but it would be nasty)

So what happened?

Because we only know its a room, we don't know if its got any special characteristics. We don't know if its just a room or if its a bathroom or a kitchen or... you get the idea.
So if we don't know what it is how do we use its, unfortunatly for us the computer is even dumber than we are. So it won't know either. Luckily there is a solution. A couple actually.

1. All classes has a getType method. Even if you don't put it there. That is because without you knowing it any class you create in either java or c# and even now a days in vb EXTENDS the "base class". If you haven't caught that, that does mean you can refer to any object as the base object. This class has nothing much in it except one or two little useful methods. One of which is getType(). Yippeee we're saved. Well kinda. The problem is that even though the objects base knows exactly what it is, if we have it defined as a room and not a bathroom we will only be able to tell you things about the bathroom that it can tell you about the room. If the wall colors were different it could tell us that or if the floor was tiled we'd be okay. But it won't be able to tell us anything about the bath, so we need to change what we have it defined as a room to a bathroom. In object orientation this is known as CASTING, and you only need to CAST if you are going from a simpler to a more complicated class. Like from a room to a bathroom. So first we cast our room to a bathroom and then we ask things about the bath, but at least we could call the GetType method to figure out what to cast it to. I know, computers are dumb! The sooner you learn this the better.
2. Instead of using the GetType() method, you could always add a room name to your checklist in your interface. That way you know you would always have to define it and you'll always know where it is.
3. Strangely enough, mostly it either won't matter or you'll know exactly what kind of room or object you are dealing with. The most common CAST you will ever do is from a base object to your object of choice (see point one on for note on the base object).
   

Now lets talk a bit about SCOPE...

I gave a builder the same set of room blueprints 20 times. He made 20 rooms. I don't like the color of my room I'm going to use as my kitchen so I paint it blue (never said I had fashion sense). Does that imply all my walls in my house are now blue because I changed one? Of course not! The rooms have been built, they now have very little to do with class or blueprint that made them except that you can probably get a good idea of what its supposed to do from the class. Once the room has been built its an individual. It can have its own fashion sense it can be used for different things. What happens to the one does not happen to the other. Same is true for classes and objects.

And that brings us to REFERENCES. OK now after a couple of years we have plenty of houses with plenty of rooms. We now need to refer to Daniel room. His room already exist, its been long built, probably customized. So we don't need to give it to a builder, we don't need the class. We already have it. So we just can just REFER to it.
So Daniel just won a room makeover. but there are many different people involved. So they each need Daniel's room to do their thing. We don't need to give them each a copy of Daniel's room we just need to let them know where it is. Anyways a copy won't work in the object orientated world because changing the colour of the walls in one copy won't change it in all the other copies of Daniel's room like magic.
So we jot down Daniel's address and room number on piece of paper and give it to all involved. We can write as many pieces of paper as we want REFERRING to Daniels room, it'll still be the same room. Even if one of the specialists write the address for someone else and they go find it and work on it it will still be the same room so at the end of the day I'll have my home entertainment system, my PS3 and my slightly scary new bedding all in the same room.
98% of objects gets passed via references, so be careful of passing an object to something, changing it and expect it to come back the same way. If you pass someone a reference to your object and they change it they will be changing your object! Its actually quite a mission to copy an object so always assume you are passing a reference not a copy.

OK enough for now, I've already given away that I watch way to many home decor programs! What can you do, BBC loves the things.

Hope this helps someone. I'll try extend on it at some point in the near future.