The reason some people say to not put getters and setters in is the tell-dont-ask-principle.
It is there to prevent unrelated objects from mingling with the guts of your object. If you have getHealth and setHealth anyone can just look inside and change it.
If you instead have applyBonusHealth, receiveDamage, receiveHeal, isAlive the Enemy object can have all related validation and logic which belongs into it.
The reason some people say to not put getters and setters in is the tell-dont-ask-principle.
It is there to prevent unrelated objects from mingling with the guts of your object. If you have getHealth and setHealth anyone can just look inside and change it.
If you instead have applyBonusHealth, receiveDamage, receiveHeal, isAlive the Enemy object can have all related validation and logic which belongs into it.
Frob ;) the way you speak of it as of SW design.. could you .. show me some small example of it? Kinda I have issues to imagine that without some pseudo code.. If you dotn mind of course... ;) Thank you..
And sorry for my english.. I know its not good.. English is not my native language.
Have you looked at many game engines before?
Even if you don't intend to use them for your game, it may be worthwhile for you to download and install both Unity and Unreal and spend a few hours following their simplest tutorials. (You might also look at the Source engine if you've got time, although it is less friendly to beginners.) While their designs are completely out of scope for a homemade engine, many of their better practices can be followed easily enough.
Often beginners have little or no exposure to the way engines work, and since both of these are freely available there isn't much excuse for having zero exposure to them. While they have their flaws, they also do a lot of good things in them.
These major engines have many systems that work together. They are not just trying to be "proper OOP", but are trying to isolate concerns and interfaces, creating using building blocks that can be reused. Playing around with them in a large, live system is probably more instructive than a few code snippets of static text.
Well, to be honest, I have never seen any engine, I am quite problematic in making games.. I kinda have absolute zero experiences and knowledge in SW design.. So this cause me a lot of problems.. I had many times problems with rewriting whole projects so I actually stoped working on them.. But what you just described is a lot worth to look at it.. I'll try it then, Thanks a lot!!!
Sorry, missed this one and it was just asked about in a private message:
For this code, isn't there a better way to represent or refactor it out of the code completely?
If your goal is to expose the values, that is no problem.
What you've got there works just fine, especially in a header file. That is, in c++ those function calls can vanish completely thanks to the optimizer's magic, with the values accessed directly from memory without any indirection or function call overhead.
But if you are working with systems, it may not be as good. If you have a set of systems that handles position then the object itself probably doesn't have the x and y coordinates, it probably has a reference to its location in the spatial tree. Similarly the health component might be a reference to another health system. That might be handled with a single indirection: void SetAlive(bool status) { myHealth->SetAlive(status); } or it might be more involved if you have custom processing to do.
It really all depends on how your system is organized and designed.
The recommendation to play with existing major engines is still there. Once you've been exposed to better engines it can help you think more about how to reuse and how to work with systems rather than focusing on the smaller pieces.
