Thread: Explain Object-Oriented Programming Like I'm 5

I'm an experienced C programmer, but I don't know that much about C++ and I'd like to know why it's better, worse, or just as good.

I'm probably just ignorant, but to me, I don't see that many benefits with classes other than for organization purposes. I know they can keep variables and functions (or "methods") private, but why would you need private variables and functions? If those variables and functions aren't to be called or accessed, then don't call or access them.

I can see why they would be useful if you're writing a library and there's certain functions you don't want your users to mess with, but why would you use them in your own programs? Aren't structures just as good for organizing your data? You can make copies of them with typedef.

I'm probably being really stupid, because like I said I don't know that much about OOP, these observations are just from what I know of it.

Even in your own code it is easy to do things you shouldn't. Programmers make mistakes that, in hindsight, are often unnecessary mistakes. You may write the documentation incorrectly. You may forget about some special but important case that should be avoided. Even in your own code.

In fact, often especially in your own code. You are more likely to be over-confident that code you wrote works correctly, and that you understand it.

Access control (private, public, etc) is about allowing you to control what code is allowed to do a change, and what is not.

Originally Posted by Babkockdood

I can see why they would be useful if you're writing a library and there's certain functions you don't want your users to mess with, but why would you use them in your own programs?

I take it that you recognise that the notion of implementation details being private in some way to the implementation maintainer is useful - this would be the notion of encapsulation. Another thing that you may recognise is that it may be useful to refer to an interface consisting of a set of functions that operate on some kind of data structure as a single entity - this would be the notion of an object or a class.

Originally Posted by Babkockdood

I don't see that many benefits with classes other than for organization purposes. (...) Aren't structures just as good for organizing your data?

If we just compare C++ concrete classes/structs with C structs, then yeah: the main difference would be member functions and access control. Member functions can be considered syntactic sugar since objects of a C struct type can also be seen as an object in an OO sense; a function that operates on the C struct and which forms the core interface provided by the library author can be seen as a member. An access control mechanism as a language feature is nice but unnecessary as convention can also work to achieve encapsulation... or we could use the opaque pointer idiom if necessary.

I think that it is more interesting to consider the use of inheritance and polymorphism thereof in C++. Start by reading about the Open-Closed Principle and the Liskov Substitution Principle.

Originally Posted by Babkockdood

I'm an experienced C programmer, but I don't know that much about C++ and I'd like to know why it's better, worse, or just as good.

One way in which it's better: the convenience of the STL containers.
One way in which it's worse: it is a resource pig compared to C, at least if you make much use of, eg, the STL. The significance of this depends on the nature of the task, I guess.

I find a lot of the syntax awkward, but I'm now learning Java -- also a strongly typed OO language w/ generics -- and it seem to have some of the same complications.

I'm probably just ignorant, but to me, I don't see that many benefits with classes other than for organization purposes.

I think that is true, but it is also true of functions, and has almost as significant ramifications. The difference between "procedural" and "object oriented" is slightly ambiguous in reality; if you think of it on a micro level, class methods are procedural code. If you think of it more meaningfully, on a macro level (the way everything as a whole is organized), you may easily find that they way you already write code could be described as "object oriented"; it is intuitive and logical anyway. I'd actually say most of the C projects I've ever looked at are essentially object oriented in at least a protozoic way, very often explicitly. Certainly, it is easy to think of them that way. OO makes natural, modular sense.

So the formal OO system in C++ provides some additional "power features", such as tidy inheritance, that are pretty useful for organizational purposes, and as such, can save you a significant amount of work (just like functions) and help "de-complexify" to a large extent. I find there is a sort of "complexity barrier" with coding; OOP simplifies IMO, making it easier to keep that barrier at a distance.

I know they can keep variables and functions (or "methods") private, but why would you need private variables and functions? If those variables and functions aren't to be called or accessed, then don't call or access them.

That's how I feel too, but then, I've never (yet) done significant work as part of a large team. In which case I might be very grateful to be able to disarm my co-workers in this way.

Aren't structures just as good for organizing your data? You can make copies of them with typedef.

Yeah, that's the kind of "primitive" or casual OOP I was talking about. C++ classes evolved from C structs.

I'm probably being really stupid, because like I said I don't know that much about OOP, these observations are just from what I know of it.

There is more OO code and less OO code. I think you start out writing more procedurally, making use of classes where you see it as obvious and convenient. Gradually, as the potential relationships between classes unfold, you start to see more and more stuff in that light. Again, exactly like functions. In general, the more you can break a task down into functions, the better. I suppose there could be such a thing as code which is too object oriented, just as there can be code which is broken down too much into functions, but I would place that bar very low, like near the level of obviously joking around. Some people are unintentionally silly, of course, but I like to think I'm not one of them.

In short, I'd say that object oriented programming is not contra procedural programming at all. It just adds a sort of meta perspective to it, opening up and structuring different possibilities.

Originally Posted by CommonTater

C++ and OOP in general are the fine art of taking a device that needs finely grained step by step instructions and getting it to act like it works on blobs of data as unified objects.

Laughably this is touted as an attempt to make programming more "human"... I don't know a single person, programmer or otherwise, who thinks like a C++ data object...

This is a very perverse, polemical mis-interpretation, unfortunately. Like I said, it is a mistake to understand OOP as something that is alien to or incompatible with "procedural" thinking.

If you are trying to discredit something, a straw dog is useful. But if you are actually trying to understand it, don't chase the straw dog. It's not what you are looking for.

Originally Posted by CommonTater

The only way I can get my head around it is by imagining classes, interfaces and objects to be little machines where pulling one lever does one thing, another lever does something different...

A little better, if only because it is so general. :P

Originally Posted by Epy

(as in, I'm retarded for not having learned C++ sooner)

Nah, your real mistake was going with the trendier python instead of the more expressive perl.

Thanks for all the explanations. I'm starting to understand it better.

Originally Posted by Epy

Perl's syntax just makes me puke blood...

That's what it's for. You need to get that crap out of your system and purlify. Embrace concise dynamic beauty kind of thing. Eventually it feels good ;$