Deciding whether a variable should be a member of a class or a local variable may not be clear to newer developers. I have always found the following rule of thumb to work best:
If it can be local, make it local.
That is, if at all possible, make the variable local. Making it a class member should be a last resort, not the default. Why should local be preferred over a class data member? For the same reason that local variables are preferred over global variables. Local variables are easier to understand. They only exist in the block they are defined in and can only directly influence code in this block. Data members exist for the entire lifetime of the object they are part of. Determining if they are initialized correctly and their effect requires one to look at every method of the class. In a multi-threaded environment, synchronization of access to data members is another complication that local variables do not have. Data members also increase the memory footprint of your objects.
Variables that should be data members are ones that hold the persistent state of the object that must be maintained between method calls. Variables that hold transient values that are only needed temporarily should be local variables.
So when reviewing a class, look carefully at each of its data members and be sure that you can justify why it's a data member and not a local variable. If you can't justify it, fix it.
5 comments:
You touched on it lightly, but going back to a multi-threaded application. This is especially true when working with web applications (when a request gets processed in their own thread).
By keeping things local instead of a member variable, it makes it much easier to use IoC/DI for those classes and only have one instance. This will limit down the possible affects on other requests.
From the performance point of view local vars are almost always faster compare to members.
Here are the reasons:
1. Compiler optimizer will most likely optimize locals to be on CPU register. Members would never get that kind of treatment from a optimizer. Yea, few exceptions for some compilers, but generally not the case.
2. Locals are always allocated on a CPU stack compare to heap for members. Memory on a stack are always faster to allocate and faster to fetch compare to memory on a heap. Again, yes some languages/compilers allow members on a stack, but generally they allocated on a heap.
For a critical performance code sometimes it is necessary to copy a member to a local var just to make access to it faster.
Good points about using local variables where possible. I have been bitten before by trying to place a variable in a class or library, only to later forget it is there and ending up with a conflict.
BTW, thanks also for the PC Assembly book on-line. I have found it useful. I am interested if you have any thoughts on programming in Python?
I'm going to agree with you on this. If you keep the variable local, it makes things a lot neater in the large picture. If something gets messed up, you'll be able pin it down to a more local area. Thanks for the tip.
-Kevin
Post a Comment