Once you go OO, you never go back?

I was scared to jump into object oriented programming, and avoided it for months when I first began programming. But once I began programming in an OO way, I never wanted to go back to the old days of declaring variables and functions outside of classes.

I guess my questions are:
-Is this average?
-Are there any modern games, that aren't programmed in an OO way?

When someone "gets" OOP, it's somewhat of an eye opener and what you experience is probably typical. It's a great tool, but don't be fooled into thinking it's the ONLY tool. There will be plenty of times when the correct tool will be a non-class function and variables.

As for any "modern" games programmed in non OO? I'd guess probably not, but not too long ago, (late 90's, early 00's) many big games were done in pure C.

I have no statistics so I'll make unsubstantiated sweeping generalizations instead

Most places outside of games DEFINITELY do OOP, whether or not they understand why they are using it and its advantages and disadvantages. Most game studios/engines I'm aware of also do OOP. I've seen a very small shift away from OOP in favor of thinking in terms of data transformations.

In my opinion OOP is very often a good choice. But unfortunately it seems like this is the way *everyone* learns how to program and don't understand the pros/cons of that style. "This is the way thou shalt make software."

You benefit from OOP by easy data hiding/encapsulation, and if we mean OOP as in common language features, ability to use polymorphic functions and type safety/inheritance. It's also a well-understood style by the person coming behind you.

A bad side of OOP is that few people succeed in only having a single concern per each object type and so what often happens is you get large classes that throw a bunch of unrelated functionality together with its data, and it makes it very difficult to extract a single aspect of the class out for reuse. You end up creating generalized objects that are more complex than necessary to solve a problem. OOP is also a trap for people to make code that attempts to model the real world (i.e. your objects are "chair" or "car" when maybe the better solution would be SitableComponent or DrivableComponent that's attached to something more general). It's difficult to have the discipline to break down a seemingly simple object into the various concerns it has, but failing to do so makes bad OOP designs.

One alternative might be a data transformations style, where you have lots of homogeneous data and you simply rip through it all using loose functions. Even with such a style, you can think in terms of OOP and limit how/when/where you access data in those lists. And yet you can keep data and logic separated. In other words, you can get the advantages of OOP without using the class keyword.

I think OOP is so prevalent because it's almost always a decent solution and it's very intuitive. So for big companies that just want to grow a workforce of moderately skilled people who can make standard business software without needing to have the depth of understanding to choose what style to use, OOP is a good choice.

I think the most important thing is realize that you can get the benefits of OOP without using the class keyword, while skirting the negative aspects of it by either being careful to keep your objects single-minded or thinking in a more raw form of data transformations in sequence. Consider many solutions/styles and *think* about the tradeoffs you make with your choice.

Actually a "new" paradigm is getting increasingly popular called Data Oriented Design: http://gamesfromwithin.com/data-oriented-design

For example, Bitsquid engine uses it: http://bitsquid.blogspot.pt/2010/05/practical-examples-in-data-oriented.html

I've been rewriting some parts of my engine to a more data oriented approach instead of object oriented, and once you start thinking data oriented you'll see a lot that a lot of your object-oriented code could probably run faster if it was data-oriented.

In my opinion, after starting to write OO code, most people fail to write code that takes advantage of the memory cache effectively...

In some situations, you will want to go back to non-OO for performance reasons. Usually OO is just fine and the overhead (if any) is neglegible. However, in some situations, it can cause adverse effects to processor caches (read up AoS versus SoA), and some OO constructs can sometimes cause significant overhead.

Virtual function calls are an example of a feature that usually doesn't matter at all, but can matter a lot in some situations. In the normal case, you pay a dozen cycles extra for the call in the worst case, mostly because the call cannot be inlined. In the average case, it's often rather something like 3-4 cycles. Burning 3 cycles a hundred times is exactly nothing for a modern CPU.

Now, in the worst case, you do a million calls per frame and the object type varies almost every time, and there are a few types to choose from, so you pay for a data cache miss, a branch misprediction, and an instruction cache miss. Multiplied by a million.


EDIT: Found what I was looking for, there is a good summary on the pitfalls of OO: http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

I remember there being another one (if I could find it now... I think it was on Gamasutra or something from GDC) which was much more radical, entirely condemning OO for performance reasons. That's a bit too harsh in my opinion. OO Performance can become a problem, but not if you are a bit savy.

As was mentioned - remember it's one of many tools, and tools, while they can be typically used for just about anything, are usually specialized for certain things. (I could go cut a board in half with a screwdriver, given enough time, but better to use the saw for that and use the screwdriver for what it's meant for.)

OOP tends to be a good fit for self-contained black-boxes that don't (usually) know about the inner workings of each other. This allows them to be highly reusable for many situations. A fantastic example is a GUI system.

Procedural programming tends to shine when it comes to algorithms and complicated ... procedures. Take code for reading/writing JPEGs for instance. I've seen this done with minor use of OOP (by Intel, in fact) and it was very awkward. I've also seen it done fully procedurally, and it is just easier to follow.

Data Oriented Design is another way of thinking that is getting a lot more attention lately (it is nothing new though). This has more to do with layout and memory structure being the first thing on your mind, and so can then be wrapped up in whatever little package you want, whether it is using OOP idiom, PP idiom, or something else.
(Note that just because you use SoA does not mean it isn't wrapped up in a nice neat little object)

There's also functional programming, stack based programming, event based programming, etc... but most of all you will find what works best and what doesn't - and more importantly why, as you get more experience. So even if you just keep doing what you're doing, and pure OOP comes back and bites you hard, it's good - that's how you must usually learn!

After you understand OO, you should try functional programming too. Not all languages support it properly, but you can usually manage, even with Java. Learning functional programming will help make your code more maintainable and bug free, even if you use OO. The best part is that you can mix and match OO and FP(though some people think OO and FP are mortal enemies. IMO they are wrong)

Well I started in python (without using its OOP features particular), then VB.net and C# which are of course OOP (and I do use OOP for my computer science coursework) but outside of school I've been playing with a little bit of plain C so I have sort of gone into OOP and then out of it again. C is for an embedded device btw, anything I develop for actual usage would normally be C# although I might consider C++ one day.

After being a C++ programmer for a little while and dabbling with Java, I have to say that in my opinion object-oriented programming is relatively worthless to me. I honestly don't see why I should ever bother worrying about whether or not a particular set of functions can "see" each other, or whether or not I can make two functions with the same name. Why would I ever want more code obfuscation like that -- two functions with identical names that can do two completely different operations? Why on earth would I ever want such a thing?

But this is of course only my opinion. I'm not unique in the way I think, surely, but I'm also probably not at all a rare, dying species of programmer.

A recent example that I can think of is the IW engine (used in every single major Call of Duty title). It's based directly on the Quake 3 source, so I can imagine it's probably in C still.

whether or not I can make two functions with the same name. Why would I ever want more code obfuscation like that -- two functions with identical names that can do two completely different operations? Why on earth would I ever want such a thing?

You wouldn't, that would be dumb and you'd deserve to be shot out of a cannon into the sun.

What you might want however is a function which does the same logical job but can support multiple function signatures for the parameters; at which point its not so dumb.

This also has nothing todo with OOP.. but then again most comments about OOP both in this thread and beyond generally have very little todo with it (at best they focus on an implementation detail of language X) too so.. ya know.. whatever.

I honestly don't see why I should ever bother worrying about whether or not a particular set of functions can "see" each other, or whether or not I can make two functions with the same name.

This gets worse when you work on big projects. You can easily lose track of what each part of your code is responsible for and debugging becomes hell.
You have to study OOP to understand. And by studying I mean really studying the paradigm, independent of a language. Looking at a language grammar and all its possible sentences you cannot see why something is useful or not, but when you study the concept behind it you start seeing the power each sentence has.

Why would I ever want more code obfuscation like that -- two functions with identical names that can do two completely different operations? Why on earth would I ever want such a thing?

That is your job as programmer to tell. You are the one that decided if overloading a function is necessary and what they will execute. Who said that different implementations of a function should be completely different?

I don't know any good books to teach Object Orientation (maybe someone can suggest one). I had to take a course on that at the university and I thank my teacher for teaching us the paradigm instead of Java or C++.

Note: I am not saying you should use OO on your projects. I am just saying that you should learn it to understand how it works. Knowledge is power in my opinion

I find OO to be a very good fit to represent most of game logic... but it is VERY easy to overdo, especially inheritance; I have seen demented usage of inheritance in my career.
I can say I had my period with OO obsession , now I am enjoying the freedom you get from C++ and understanding that lots of things live much better as loose functions... so I would say no, you actually can go back from OOP, and just use it where it's the best fit for the problem.

I honestly don't see why I should ever bother worrying about whether or not a particular set of functions can "see" each other

this will become tragically clear once you'll try to debug a big project where everything can talk and modify everything else.. at that point it becomes really hard to figure out what's going on... this, again, has nothing to do with OOP but more to do with global state and basic programming theory.
Of course, from a programmer's point of view, being able to access every function and every variable feels like a good thing, but it quickly turns into a total mess... and the problem gets bigger as the software gets bigger, so you might get away with it with small code bases.

this will become tragically clear once you'll try to debug a big project where everything can talk and modify everything else

QFE

A lot of game code tends to be write-only, but in other programming domains maintenance turns out to be the bulk of the cost of software. Good OO design leads to well-defined interfaces and good decoupling, which in turn leads to improved testability and easier reasoning about the code, which further leads to fewer bugs, fewer staff hours for fixing problems, and less cursing and grumbling (and lower staff turnover).

OO is a very useful design tool. It can be a very useful implementation strategy. So-called Data-Oriented Design is a refinement of OO using many of the techniques pioneered for procedural programming in the 1970s by the likes of Coad and Yourdon and rediscovered recently by people who didn't pay attention in computer science class.

As for the OP, congrats on gaining the OO achievement. Keep playing, the game's not over yet.

After being a C++ programmer for a little while and dabbling with Java, I have to say that in my opinion object-oriented programming is relatively worthless to me. I honestly don't see why I should ever bother worrying about whether or not a particular set of functions can "see" each other, or whether or not I can make two functions with the same name. Why would I ever want more code obfuscation like that -- two functions with identical names that can do two completely different operations? Why on earth would I ever want such a thing?

But this is of course only my opinion. I'm not unique in the way I think, surely, but I'm also probably not at all a rare, dying species of programmer.

Most of the projects I've worked on professionally did NOT do much in the way of data hiding. 99% of the member variables in a class were public. It was annoying at times.. every time you reached in to set a value you had to be careful that you wouldn't cause side effects, but ultimately those projects shipped. Unrealscript is an example of an everything-is-public OO implementation.

Data hiding is a good idea. But can you ship without doing it? Yes, definitely. It raises the requirement of others not screwing up when working with your code though. In the case of unrealscript, they made the explicit choice to not hide data for performance reasons of calling a getter/setter (in C++ it's essentially no extra cost due to inlining, but in script.. there was definitely cost.) But that decision was not without other consequence in the form of maintenance hassle.

this will become tragically clear once you'll try to debug a big project where everything can talk and modify everything else.. at that point it becomes really hard to figure out what's going on... this, again, has nothing to do with OOP but more to do with global state and basic programming theory.
Of course, from a programmer's point of view, being able to access every function and every variable feels like a good thing, but it quickly turns into a total mess... and the problem gets bigger as the software gets bigger, so you might get away with it with small code bases.

I think I can safely say that the above is pretty much a nonexistent issue. In C, you cannot "access every function and every variable"; a static int declared within a function remains within the scope of that function, and cannot be overwritten directly. Of course, it's quite possible to do so intentionally, in the same way that it is with any OOP language that doesn't do bounds checking on arrays, if you get where I'm going with that.

If I don't want a function to modify something, I'll pass it a pointer-to-const (i.e. const int* var; ). If I want a variable to be available locally to a function, I will initialize that variable within the function that requires it. Not much more to it than that, honestly. If it comes to a point where data is being modified that I didn't intend to be modified, I can always have a look at that nifty map file the linker generates, which is available to both C and C++ programs.

You may get stuck in a rut of OO-obsession for a while, but you'll come out eventually as a better programmer For me, C++ tends to demand a bit more thorough OO style than I prefer, especially for games. C is like a blank canvas, where you can use OO techniques without having them pushed in your face, and mix and match with other styles less awkwardly. But it works best when coding alone... for group projects, C++ usually works out better in the end. You can still mix and match styles, but do expect to have a high percentage of your code end up as strict OO.

I also agree with Drathis, that OO and functional programming mix surprisingly well. Definitely another good tool to have in the box

[quote name='kunos' timestamp='1355938622' post='5012513']
this will become tragically clear once you'll try to debug a big project where everything can talk and modify everything else.. at that point it becomes really hard to figure out what's going on... this, again, has nothing to do with OOP but more to do with global state and basic programming theory.
Of course, from a programmer's point of view, being able to access every function and every variable feels like a good thing, but it quickly turns into a total mess... and the problem gets bigger as the software gets bigger, so you might get away with it with small code bases.

I think I can safely say that the above is pretty much a nonexistent issue. In C, you cannot "access every function and every variable"; a static int declared within a function remains within the scope of that function, and cannot be overwritten directly. Of course, it's quite possible to do so intentionally, in the same way that it is with any OOP language that doesn't do bounds checking on arrays, if you get where I'm going with that.

If I don't want a function to modify something, I'll pass it a pointer-to-const (i.e. const int* var; ). If I want a variable to be available locally to a function, I will initialize that variable within the function that requires it. Not much more to it than that, honestly. If it comes to a point where data is being modified that I didn't intend to be modified, I can always have a look at that nifty map file the linker generates, which is available to both C and C++ programs.
[/quote]

That's an awfully big limitation to put on your data (requiring it to be a static variable in a function).

Also (regarding the const thing), data-hiding isn't just about worrying about modification. If you have a publicly visible piece of data and you change its representation/meaning somehow, you have to worry about everyone who may access that data. Making it explicitly clear who has access to that data really is essential for building/maintaining robust code.

If you work on a large project, you will quickly realize this is not a "nonexistent issue".

If you started with OOP 20 years ago well... yeah, you could say that. Right now not so much, I don't think so.

I've tried to understand how Data-Oriented Programming works, but it just doesn't snap into your mind like OOP did.

Also, are there specific languages for DOP, like there is for OOP?