[newb] Can someone explain the advantages of OOC?

As the thread title says, I'm looking for someone who can explain the advantages of object oriented coding to me.

I have a background in PHP, got certified in it, but I never managed to figure out why I should use object oriented code over just a bunch of functions.

I'm having the same issue while going through the C++ tutorials provided on the website, and I always hear people talk (post) about how good object oriented coding is, and alike.

The examples on the website tell me that it's basically to make things easier to use.
One of the examples given is that, if you had a microwave, it would become less user friendly if you had to work with the microwave's 'internals' as opposed to it's keypad.

Now I don't really see this example (though I'm sure it's just an example to make it easier to understand), to me, makeing that microwave object oriented, and only giving access to the keypad seems strange if you consider that, object oriented isn't "smaller" or "more compact" then regular code.
So in the example of the microwave, a non object oriented microwave would basically be a regular microwave with the casing removed.
Now, to a developer who knows that microwave inside out, that could mean easy access through the keypad, plus possible extra functionality through the internals. Ofcourse, to a consumer it would be very dangerous, but that wouldn't be relavant unless said consumer would first decomepile our microwave.

----

I know I'm probably making no sense at all, but I really intend to become a qualified C++ developer, and I'm quite sure that somehow in a way that I might not understand yet, there's a way in which OOC is useful, and basically my question is; what's useful about OOC?

The only real difference between C and C++ (OOP) is the addition of CLASSES and UNIONS, soem added functionality for STRUCT's, and much stronger type requirements. Other than that You will find there are two major coding styles. 'standard' C style and C++ style which uses classes for just about everything, including things that would be better implemented as dynamically allocated structs and functions.

The pro of C++ is its flexability, some people claim its closer to the way humans think, whatever that means.

The down side is speed, both in development and execution. Readability tends to suffer as well.

Are you saying that one of the downsides of C++ or OOP is development speed? Or readability? I would say the opposite is true.

I'd also argue with the notion that C++ style uses classes for everything. Free functions are common in C++ (see the standard library).

Another difference between C++ and C is the use of templates.

BTW, C++ is much more than an OOP language. It provides facilities for many different programming paradigms.

OOP itself is good in part because it helps encapsulate behavior behind an interface and allows you to program to that interface without worrying about the implementation.

Compared to procedural programming, OO offers a whole new way to organise programs and approach problem solving. The data in your program becomes more closely associated with the processes which you need to perform on that data, to the point where you are less concerned about the raw data itself, and more concerned with what that data represents, and how you wish it to be used.

In reference to your Microwave analogy, the object oriented approach tells you that you have an object which is a Microwave. You don't care how it works, you only care that you put food inside it, and that you have an easily usable way of setting the amount of time the food will cook for. You also have various safeguards, such as the fact that the food will not start cooking if the door isn't shut.
A non-object-oriented microwave might be a radiation gun, with your food, sat on a turntable. You have to physically rotate the turntable, and hold the radiation gun in your hand, pointed at your food, guessing at how long you've been aiming the radiation gun at the food, or watching a stopwatch.

For all intents and purposes, you have the same components, and the same job is done with each approach, but the object-oriented approach doesn't have you worrying about the individual components or how to manage their behaviour. When you take your food out the microwave, you're safe in the knowledge that the microwave did its job, and your food is cooked according to the data you set when you pressed the buttons

On the other, there is also far more chance that things can go wrong when you are holding the radiation gun at the same time as rotating the turntable and keeping an eye on your stopwatch. Do you know that the food is cooked properly? did you have some nasty side effects? (perhaps you weren't aiming the gun properly and accidentally cooked some food which was sat next to the turntable aswell)

Sure the microwave is probably bigger, and more expensive, and it definitely not suited for every job where you need a radiation gun (Like a particle physics experiment needing precision perhaps), but for its specific purpose of cooking your meal, it does a nice hassle-free job.


I'm not a great fan of analogies, and i'm fairly sure that doesn't help you understand how your programs could be improved with OOP

the best example in C++ i can think of to demonstrate the power of OOP is the C++ <string> library

first of all, lets have a look at how to concatenate two strings together in C-Style, "Hello, " and "World!"

Code:

---

#include <iostream>
#include <cstring>

int main()
{
    char str1[] = "Hello, ";
    char str2[] = "World!";
    int length = strlen(str1) + strlen(str2);
    char* result = new char[length];
    strcpy(result, str1);
    strcat(result, str2);
    std::cout << result;
}

---

So its not so bad, but it's a bit fiddly, and not exactly the most intuitive bit of code.. lets have a look at the C++ <string> way of doing the same thing

Code:

---

#include <iostream>
#include <string>

int main()
{
    std::string str1 = "Hello, ";
    std::string str2 = "World!";
    str1 += str2;
    std::cout << str1;
}

---

Nice and easy huh? But behind the scenes there's probably something similar going on to the first example - new memory being constructed with new, and the contents of str1 and str2 being copied into that new memory..... but all you as the user of the <string> library sees is the simple one liner, str1 += str2; - You also don't have to worry about the length of the string, because thats all taken care of. Had you tried to simply strcat() str1 and str2 together in the first example, you'd have ended up overflowing onto memory which didn't belong to you. the C++ string class takes care of all these worries for you, and presents you with a neatly wrapped interface, hiding from you, the nitty-gritty stuff you don't need to know.

I find OOP absolutely essential to any project of a moderate to large scale.

Despite what people say, OOP isn't really about code reuse or faster development time. Its about organization.

There comes a point where it is simply impossible to write a program without abstracting certain parts off. Unless you are superhuman, you will hit a point where the project just cannot continue without separating code off into different sections.
As you suggest, it can be done with functions, and it sometimes is, but functions can only go so far.
This problem is compounded even further when you are working on a team. Can you imagine how difficult it would be to interface your code with someone elses?

OOP is about encapsulation, opacity and extendability. Really, OOP is just like the libraries you use. You can finish parts of the program and package them off. While the microwave analogies are somewhat distant, imagine a situation where you need to interface with a database. This is a perfect place for OOP.

You can code your entire DB driver, and then package it off into a class which provides complete opacity. You no longer care how it works, you no longer need to worry about if it works, you can use it in whatever project you want. It doesn't even matter if you coded it.
The equivalent done with functions, no matter how clean you try to make it, will always be messier and less reusable.

There are places for OOP, and as you learn more and look for solutions, it will grow on you. There are so many advantages to using OOP if you just look for them, and it makes programming much easier.

Another example, lets say you are programming a RTS game and you are working on the AI. Frankly, I would consider it impossible to code the AI without oop. You must remember that there could be anywhere from 0-## computer players in the game at a time, and AI is no simple program.
Just as done with the database, you can abstract it off and provide a simple interface. Say give it a constructor to provide it with some basic values for difficulty, and then let it take care of everything internal. Provide an easy and simplified method for it to tell you what it wants to do, and provide a simple way to give it the data it needs.
Suddenly, your AI can be instanced hundreds of times, and runs essentially as a completely separate program. Its done, you don't have to touch it with a 100' poll. You know it works, you don't need to search it for errors twice a day.

And then there are design patterns...

Thanks to everyone for the replies, personally I havent really worked in team projects much before, but I can imagine how OOP would make a difference. Also thank you for the AI characters example, it's a good example that's helped me a good bit in understanding why and where this becomes useful.