code structure question
BlitzMax Forums/BlitzMax Programming/code structure question
| ||
| hey guys, while designing a new system on paper I've raised a small dilemma as to choice, and wonder if it is simply about style, readability, or best practice. Let us say I have an object. Before this object is drawn, the transparency is set using setalpha... based on a variable current_transparency. So this object's image will always be drawn at the value of current_transparency. Let us say now I am doing a check elsewhere on the transparency of that object, to decide to execute a piece of code based on the result. Is it better to use If object.current_transparency > XX do code end if Or write a getalpha() method for the Type containing the object like method Getalpha() return current_transparency end method I know getalpha is a reserved word in blitz but I am just using it as an example here, the value could be any value we were trying to get. Like speed, or damage or something. Where would I want to use the latter option, and what is the benefit over the former? |
| ||
| Technically for the sake of keeping an object encapsulated as it should be, the correct way would be to use setters and getters such as getAlpha and SetAlpha. Personally I hardly ever use them and although I like to program in OO style, I refuse to write a method for each of the field variables I need access to. so I do it as your first example most of the time but I do use them in some instances. So If you want to do it by the book do it that way, with setters and getters. I don't endorse it because I don't force myself to do it but if you want to do it by the book then use setters and getters. |
| ||
| Where would I want to use the latter option, and what is the benefit over the former? You would use it when you don't want user to access the value directly, in order to prevent them setting it to something invalid. 1) If you are the only person who will ever use this module, then there is no benefit to using a getter method, except to feel smug about being stylistically correct. Since you have full control over the code, if you wanted to do something invalid you'd recognise that as an insufficiency of your design and change the rules at the design stage. 2) If the code is for other people, then using access methods is a useful way to keep them under control, but it will only work if you hide the implementation details behind the "walls" of a module (note that this requires the method and the field to be in separate types, or it achieves nothing). Otherwise, they have the same freedom to do whatever they want that you do as the author. 3) If there is no way to use this field in an "invalid" or "unsafe" way, then there is no real reason to ever wrap methods around it, no matter what happens. If you aren't used to module writing yet, then you may as well stay away from this whole thing. The truth is it's really an imported concept from other languages that have different security features, and 99% of the time doesn't apply when writing BlitzMax code. So unless you specifically want to protect a field, writing like this is unnecessary effort. |
| ||
| thanks guys! so basically I can stick to ordinary condition checking, like IF and select statements. This came up when I am designing an encounter system. Checking the players standing to the people he is encountering and executing which code based on the standing. |
   |