My understanding is any method which does not modify state of the constaining class is a prime candidate to be made static because it does not touch the instance. An instance would be that containing class’s data (fields/properties) so if I had a person class with a property called Name (and just that one property), and I am not modifying that property then my class can be set as static, but of course, but the function could be working with another object. Is this the right thing to look for when checking if a method should be made static?
Static variables are described as global variables, but what is the difference of this to any publicly variable? All the variables are in the server’s memory and will be lost in a reboot etc. And then use this variable to hold expensive-to-get data (eg running stored procedures in a loop etc).
Thanks
I don’t think this is the right way to think of static vs. non-static. Rather, any method which is not related to the state of a class instance can be static. A name is obviously associated with a particular person, so a
Namefield on aPersonclass should almost certainly not be static. Otherwise, you could end up with a scenario like this:EDIT: Now, suppose we have a property such as
Housewhich can belong to not one but several people. blade asks: “How would this be modeled in code – static?”My answer: NO, for the same reason already mentioned above. Suppose I’ve fixed the problem above by making the
Nameproperty non-static. Then I introduce a new staticHouseproperty. Now I have a situation like this:There’s a difference between multiple objects of one class sharing the same object and ALL objects of that class sharing the same object. In the latter case, a static property makes sense; otherwise, it does not.
There are a few ways off the top of my head to deal with this scenario. They are:
1. Make the House property non-static
It might seem strange, but you can always just make the
Houseproperty non-static and you won’t ever have to worry about the problem above. Furthermore, assuming you actually do assign the sameHouseobject to eachPersonwho shares it, making a change to theHousethrough onePersonobject will actually achieve the desired effect:This could actually be a problem, however, if you accidentally assign the same House to two people with the intention of them actually having two different Houses:
2. Use a database
The fact is that the notion of making a house a property of a person is somewhat a forced concept to begin with. A person may move out of their house, different people may move in, etc. Really a relationship exists between the two, which makes using a database an appropriate solution.
Using this approach, what you’d do is have a
Personstable, aHousestable, and a third table (maybePersonHouses) containing id pairs from the other two tables to represent, I guess, home ownership.If you don’t have a full-blown database at your disposal, you can achieve effectively the same result (in .NET) using a
System.Data.DataSetand its collection ofSystem.Data.DataTableobjects in your code. However, in any scenario where you are translating rows of a database (orDataTable) to objects and then back again, you do need to be aware of impedence mismatch. Basically, whatever meticulous precautions you take in your code to encapsulate your data are out the window once that data is in the database, ready to be modified by anyone with sufficient permissions.3. Use dictionaries
Another approach, similar to using a database but a bit more work (and I think some programmers who’ve gone the
DataSetroute shudder at the thought of this), is to use dictionaries to keep track of yourPersonandHouseobjects. The quickest way to implement this approach would be to have aDictionary<int, Person>and aDictionary<int, House>, and assign eachPersonaHouseIdproperty:This way, all your data encapsulation still holds. However, if you ever need your data to persist between instances of your code running, then you need to serialize your dictionaries in some file format (most likely XML), which could then be edited by anyone with sufficient privileges, and then you’re back to the impedence mismatch problem of using a database all over again.
In light of the advantages and disadvantages of each approach, I think what actually makes the most sense — and makes your life easiest — is to simply make
Housea non-static property. This is assuming you don’t have tons and tons ofPersonandHouseobjects to keep track of.