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.
