For C/C++, When is it beneficial not to use Object Oriented Programming?

Question

I find myself always trying to fit everything into the OOP methodology, when I'm coding in C/C++. But I realize that I don't always have to force everything into this mold. What are some pros/cons for using the OOP methodology versus not? I'm more interested in the pros/cons of NOT using OOP (for example, are there optimization benefits to not using OOP?). Thanks, let me know.

Answer 1

Of course it's very easy to explain a million reasons why OOP is a good thing. These include: design patterns, abstraction, encapsulation, modularity, polymorphism, and inheritance.

---

When not to use OOP:

• Putting square pegs in round holes: Don't wrap everything in classes when they don't need to be. Sometimes there is no need and the extra overhead just makes your code slower and more complex.
• Object state can get very complex: There is a really good quote from Joe Armstrong who invented Erlang:

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

• Your code is already not OOP: It's not worth porting your code if your old code is not OOP. There is a quote from Richard Stallman in 1995

Adding OOP to Emacs is not clearly an improvement; I used OOP when working on the Lisp Machine window systems, and I disagree with the usual view that it is a superior way to program.

• Portability with C: You may need to export a set of functions to C. Although you can simulate OOP in C by making a struct and a set of functions who's first parameter takes a pointer to that struct, it isn't always natural.

You may find more reasons in this paper entitled Bad Engineering Properties of Object-Oriented Languages.

Wikipedia's Object Oriented Programming page also discusses some pros and cons.

Answer 2

One school of thought with object-oriented programming is that you should have all of the functions that operate on a class as methods on the class.

Scott Meyers, one of the C++ gurus, actually argues against this in this article:

How Non-Member Functions Improve Encapsulation.

He basically says, unless there's a real compelling reason to, you should keep the function SEPARATE from the class. Otherwise the class can turn into this big bloated unmanageable mess.

Based on experiences in a previous large project, I totally agree with him.