I’ve been developing in Objective-C for a long time, mostly games, and lots of people have commented that I frequently use global variables. For example, in my .m file before the @implementation I mostly have:
BOOL X=0;
int y=1;
NSString *ran;
.
.
.
Now, I know I have to use properties, but I’ve found it much clearer for me to use this global variable, and I’m keeping them safe.
Except for the fact that it is not object oriented and/or not acceptable, does it affect any other facet of my app, like processor operation?
In my games I have something like 40 booleans in 1 class that are shared by almost ALL methods. I find it almost impossible to write getter/setter, or use properties for all of them, and I am comfortable with my way. But is it so wrong?
Is there another way to deal with many booleans that change in real time frequently, and are shared by all methods?
Is this so terrible to use globals? (I dont need to be considered as good Objective-C user…)
ObjC’s not much different from its relatives in this regard.
The problem is that the program is very difficult to use in other contexts. That is, it can be a better choice to reimplement a program entirely rather than making the one with 40 globals reusable (and retesting everything).
40 Booleans for one class is also a llllloooooooot. Read your code — look for patterns. Make smaller, more easily reusable implementations if you want to get away from the globals. Many devs consider them huge maintenance pains (war stories!). I could easily see myself having trouble trying to understand the program flow of such a program.
Even packing your 40 bools into a C struct and putting an instance of that struct in your ObjC class will be one huge improvement which is simple to implement.
If you have had no problems maintaining these programs, consider it a blessing! …but it will not be a favorite design for other people that will read, extend, or maintain said program.