Greetings.

I have enough experience for learning DirectX and I have to some extend but I am struggling on organizing my codes.

Object Oriented Programming is messy for me, is there any book or resource you could share to help me in my troubles?

Free online book: https://gameprogrammingpatterns.com/

@8Observer8 I had purchased this book a few weeks ago

jv001id said:
Object Oriented Programming is messy for me

what do u find messy in OOP ?

jv001id said:

Greetings.

I am enough experience for learning DirectX and I have to some extend but I am struggling on organizing my codes.

Object Oriented Programming is messy for me, is there any book or resource you could share to help me in my troubles?

OOP is messy for everyone once you start to solve complex problems. In fact programming in general gets messy. You will likely have to refactor your code several times over the course of a large project. I do this and I've been programming for nearly 40 years. In addition one person's elegant code is anther's abomination. I sometimes find modern idiomatic C++ code confusing. On the other hand I have templates with 20 template parameters and tend to have tables of function pointers and try to minimize conditions as much as possible. I'm sure plenty of programmers would consider my code confusing. In general if you are a solo programmer you need to develop a style that works for you. If you are working in a team, things get more complex as you should come up with some baseline coding practices.

@ddlox @Gnollrunner Exactly, I am trying to adopt a programing style so I can build mine on top of it. I found Entity-Component approach for engine programming rather satisfactory.

We do not know your level. Show us your best work in DirectX. If you are not very skilled programmer just do not think about OOP. Use it only when you fill that it is necessary for you. Just make a lot of small games in DirectX. Your brain will tell you something new on the next small game. Sorry for my English, I just practice.

@8Observer8 I have been practicing, that is why I've been searching for best practices on this.

Thank you.

The real struggle is not coding, it's understanding how to translate the problem you're solving to the level of 0s and 1s (ie computer data). Note that “translate” here means basically “explode into a few zillion cases that may happen, and must be dealt with”. Higher level concepts [EDIT: such as OOP or Entity-Component] make it a little easier, but they are very generic so mostly work towards raising the abstraction level a few bits and don't do much towards simplifying the specific problem.

Basically, we are very bad at handling that amount of detail. A human brain can deal with 7 things at the same time, and any real-world problem has more than that, so you have no hope you can simply grasp the entire problem the first time you look at it.

And that is why everybody struggles. With code that you write, you document your current solution, hoping it captures the problem entirely. Quite often that fails, and you find new cases you missed. This leads to deeper understanding of the problem, and consequently a different solution (sometimes even very different) and new code for documenting it. Repeat until you stop finding new cases.

The best practices are thus based on the need to adapt code often. Don't assume your current code is final, expect that you need to change it, refactor it to another form. Refactoring is a complementary skill to writing new code.

@Alberth I found your advice rather encouraging, that is exactly what I will do.. IF I do not understand the invented wheel, then I will reinvent it…. through the process I hope to understand why we needed the wheel in the first place.