An Introduction to Object Oriented Programming, As Explained to a Moron. (me)

[Torminator]

So, I am attempting to learn C#. Attempting might be too strong a word.

I've done a bit of coding in Lua, C, C++, Python, etc..., but I only actually did anything with C and Lua.

so OOP is a bit alien to me, and a lot of the concepts were just confusing. I summoned my nerdly allies on the book of faces, and got what, at least to me, was a really good explanation of the concepts. I also almost started a nerd fight, but that's another story. I'll try to replicate it here as best I can, leaving out the arguments and trying to maintain context.

Mostly, I just thought I'd put this up here for anyone else, like me, struggling with Object Oriented Programming concepts.

It's about modeling real world interactions between objects?

You have classes, which are just a collection of data (like the make, model, year, etc. of a car), and methods that the class can do (like accelerate, break, etc.).

Is that good enough?

So... A class is like a data type and a function rolled into one?

A class IS a data type.

At the highest (lowest?) level, a data type is a set of data (An int can be any integer, its data set), and associated functions (addition, subtraction, multiplication, etc.).

A class is a data type that you create.

Okay, So if we use the analogue of procedural programming ideas, an object would be a "variable" of type "class"?

Yep.

There are, at it's most basic, functional programming and object oriented programming (there is a third, but it isn't useful by itself). Functional programming is what most people think of when doing programming, and at the assembly/binary level, that is all there is. Functional programming is when you give the computer a list of instructions to be carried out in order. You can cheat a little (by writing functions, which are just named blocks of code that can be reused) but for the most part, you have to simulate whatever you are trying to achieve step by step. Depending on what you are trying to simulate, this can get hard to read. Most people don't think to simulate a car by first describing the skid of tires at the moment, multiplied by the function of momentum, and right after what the driver is experiencing, followed soon after by the radio functions. In this case, object oriented programming is more important.

Object Oriented programming attempts to define a broad overview of items in a class. A class PERSON will contain thinks like name, height, weight, IQ, etc. From the class, instances of a class can be further defined and operated on. An instance of PERSON might have name = Westin, weight = 180, IQ = NULL, and so on. While this doesn't sound useful yet, the programmer can also add methods to a class. It is safe to say that all people Eat() and Breath(). After this, things really get cool

So already, I am saving a lot of effort by just being able to say PERSON westin("Westin", 180, null) as apposed to making a whole block of code for each person that I need to make. On top of that, most OO languages allow for dot notation, so If I want instance westin to breath, I just say westin.breath(). But just defining a person is not that useful. As we all know, everyone can't do everything. So two concepts come into play, and these are what take the cake: INHERITANCE and POLYMORPHISM.

For the sake of simplicity, lets say that PERSON is defined to have a "virtual" method useComputer(). If you were to look at the implementation of useComputer(), it would likely be blank, or not go beyond { turnOn();} . I am saying that each PERSON has the ability to do something with a computer, but the average person can't do much.

We can then make another class called PROGRAMMER. PROGRAMMER is going to based off of, or INHERITS, PERSON. This implies that a PROGRAMMER has a height weight IQ, breath(), etc, but in this new class, it will also define things like debug(), languagesKnown, and other things associated with all programmers. Because PERSON also defined useComputer() as virtual, it will overwrite useComputer() with something more useful. So if instance Westin was made as a programmer, and Ozzie was... not... then when we both call useComputer(), something different happens. This is referred to as POLYMORPHISM.

Why does this matter? The easiest implication is westin and ozzie are still people, and you can collect their data objects as such, in an array if you will. If you looped through this hypothetical list of people, you can call useComputer() on all of them, but different (and hopefully more appropriate) things happen for each one. A draw loop in a video game works like this. All objects are declared drawable, and go into a list of drawable things, but their draw call is different.

I would like to add that the previously specified Polymorphism is RUNTIME polymorphism, and there is also COMPILE TIME polymorphism.

Compile Time Polymorphism is the same idea, except instead of overriding a method of the same name and argument type/list, you specify a function with the same name but with different argument types/amounts/etc.

For example, you have an Add(int, int) function and an add(float, float) function. You call them the same way, but when you call Add with integers you get the first function, whereas with floats you call the second function.

One last thing: the terms used are common to all OOP languages, so you'll never see them go away.

And C# in particular has something called properties, which can thought of as methods masquerading as variables. You use them as variables, but a function is run every time you do something with them. You can also define what is done with a variable in this way, or make it read or write only. You'll likely see them a lot in your learnings, as their hella useful.

[vyarthrot]

Try this one......Object Oriented Programming tutorial

Vyar

[ColKlonk]

Take a bet this is where KSP has it's memory leak...

What is not made obvious in OOP and critically essential to prevent 'memory leaks'..

- check if the object already exists, and not create a new one.

- is the need to unload the object once all child objects are 'deleted'.

If this is not done... you'll have all these unused objects floating around in 'memory space'.. which prevents the heap manager from doing it's job ===> BSOD

[sarbian]

ColKlonk : you need to read up a bit on managed memory langages. It does not work like that.

[ColKlonk]

I'm aware of memory managed.. but this is about OOP and if code uses it, these are a few of the the problems.

Evert DLL is essentially an OOP object and there are lots in the game, managed or not.

[sarbian]

And again it does not work like you think it does. the fact you use OOP has nothing to do with 'memory leaks'. It s even easier to leak with a classic lang like C.

[ColKlonk]

I sort of ignored this.. wondering if it's worth pursuing... a confirmed waste of time no doubt.