Man I haven't heard anybody try to justify OOP in games in a very long time. With small projects it might be okay because being fast isn't a huge concern, but there's also the problem of object oriented codebases being some of the most convoluted I've ever seen. With all these different classes, templates, interfaces, and more functions than anybody ever needs (every time I see a getter and setter with no logic in it, part of me dies), it's really easy to get lost, not knowing what code is actually running. I think something like ECS is an objectively better way to structure your code when it comes to games. You get all the speed, more modularity, and it's super easy to make more content after you've got enough components.

With the advent of cross platform games becoming popular, I think game programmers should know there is the do it yourself option. Basically these are things that game engine or render engine programmers do to get highly efficient frameworks or game engines in place. It's what I study and do, so its what I blog about. One of the points I brought up, is that this way of thinking can help a game programmer or developer get better techniques or learn tricks that may be useful in other areas where graphics programming reside, like interactive multimedia and user interface programming, which are graphics intensive.

Dont get me wrong, i like OOP and use it everyday, but to point out making everything object oriented is not the smartest way to program. Heavy object oriented code makes it harder to debug, harder to follow and harder to understand - especially when there are a lot of generics (c++ templates) going on.

Use classes, interfaces when it makes sense, but do not introduce oop just for the sake of it! Object orientation has its benefits when used properly.

- I get tears when i see classes which have literally one or two methods in it without any or useless fields

- I get more tears when i see classes with a singleton patterns just to simulate a global variable

- It hurts when i see getters and setters which does nothing than returning and setting a value.

- I starting to dislike code when i see templates over templates over templates (Std Library is a good example, even though its properly implemented and really fast)

- I get more tears when i see classes with more than 3 level of inheritance

- I get much more tears when i see constructors which does heavy operations, like doing collection lookups, file loading... that sort of thing -> Constructors and destructors should never do more than initializing fields.

A database class should never start connecting to the database when i just call new Database("localhost").

A asset class should not load any assets when i just call new TextureAsset("mytexture").

- I start to curse the developer when there are exceptions thrown in the constructor or destructor

To summarize it:

- Use object orientation when you really need it to be abstracted that way, but not the other way around! it does not matter if you do game programming or web programming or business programming whatsoever.

- Object orientation is not a holy grail to solve any problem: sometimes it helps, sometimes it can´t and sometimes it simply makes your code unnecessary complex

Thats my personal opinion after doing programming since 25 years, seeing so much code which is just unusable, just because its so much abstraction going on making it near impossible to understand or to debug.

Well, the point of the blog was just to introduce Object Oriented Programming from my perspective, as I introduce some tutorials or code sets later on, in later blogs. I am using a teaching blogging, discussion style, where some "students" or "audience members" with lots of experience, such as Finalspace, may already know the material and have experience with it, but even if 1 or 2 readers may not, it can still be useful information to them and it is worth it to present. How many times have we seen a lecture or conference, where the presenter or teacher is discussing something, and half the audience is saying "I already knew that." Well, it is definitely still useful for the other half, and even a review or discussion doesn't hurt, and can maybe help you with something or a fact or detail you might have missed :)

I absolutely agree, that sometimes object oriented code is unnecessary, and in fact sometimes you can even include repetitive functions slightly modified in different classes, if it's only used once in a while and don't feel like writing a class.

Object oriented code patterns are useful for writing utility code that provide features like Reflection in java, where all methods and classes follow the same pattern and thus can easily be searched for providing information to the search utility. This can help with more advanced features like dynamic code generation or statistical type information about large code sets. This is more so for project leads and project management, and falls into the category of software engineering.