Started programming with BASIC on the ZX-81, and BASIC and 6502 machine code on the BBC Micro. Programmed in a dozen languages since.
What's wrong with OOP? I find that's the way I think. Maybe because I started off learning C++ (when my brain was still pretty pliable) and that kind of changed the way I thought about things too. I would actually love to have a cross platform C++ (no, Java is not C++, it is really less OOP in some ways).
I have a struggle with OOP as well. I learned using BASIC. I only need data structures to hold the actual data. I use functions only to manipulate it. I tried using OOP several times.
However, I found that when I do use classes, I have to make many more objects than I actually need. Plus, I found that the data structures and functions often evolve, to do many different tasks. Using classes, when I need to make those changes, I have to update several different classes and methods, all over the place, which means that there are lots of different places for the code to fail, and I struggle to keep track of it all.
With data structures and functions alone, I can keep it all together, and when I do have errors, it's all there for me to debug.
I'd really love to learn to use OOP successfully one day, if only because everyone seems to be so into it, and I keep feeling like I must be missing out on something vitally important.
I never understood why they had to do all that stupid nonsense like "WNDCLASS" and the stupid WindowProc (and all the stupid distinctions between BeginPaint/EndPaint and GetDC/ReleaseDC). And that's just the super basic stuff.
It was designed to fit in with the existing code, that was coded in C many years ago.
Microsoft work in a very ESTP way. Their policy tends to be that if it looks good, and offers more functions that consumers will be amazed by, then it will sell, at least to the lowest common denominators, and as they are the majority, then Microsoft will make the most sales, and make the most money. As a result, if coding has a problem, then they tend to just put it out there, to make the most money ASAP, and then sort out the bugs later. As a result, they also tend to stick with the existing foundational code, even if it's buggy, because it's quicker for development.
If they really feel they HAVE to redo the foundational code, like when they redesigned the SQL Server engine, or developed the .NET framework, it tends to take years, because they are so used to sticking with what they know, they tend to duplicate what they had, but in an entirely different way.
There are some classes which will need all 3. Really, what I need now is to start coding the entity classes (that is, the units, buildings, etc.)
A suggestion here. One thing that I learned from bitter experience, is to "start with the end in mind".
Think about how you want the finished result to work. Start by building the end-result entities: landscape, buildings, weapons, characters, as extensions of general abstract classes of Landscape, Building, Weapon, and Character. Make the user into a User class, that is an extension of the general Character class. As you develop each class, add the methods and variables that you think appropriate. As you work backwards, you add all the elements that each class' dependents would need. When you get back to the very start, you now have a reasonably appropriate set of data classes, that can translate back into table for permanent storage in a database or set of files. Then you can work forwards, and add any missing code that is required to make it work.
) behind them. It just takes a lot of effort to get going (although I love planning it all out, the actual coding really doesn't suit me).
