Lesson time, gather round, were gonna learn all about static, and why you should
never, ever use it. Because it is like terrorists, I don't need to explain why it is evil, it just is.
Now, let's say we wanted a program to do our physics homework for us, because we don't need no education.
class Program
{
static void Main(string[] args)
{
Console.Write("Initial Velocity: ");
double vi = double.Parse(Console.ReadLine());
Console.Write("Final Velocity: ");
double vf = double.Parse(Console.ReadLine());
Console.Write("Time: ");
double t = double.Parse(Console.ReadLine());
Console.WriteLine();
Physics p = new Physics();
Console.WriteLine("Acceleration = {0} m/s^-2", p.FindAcceleration(vi, vf, t));
Console.ReadKey();
}
}
class Physics
{
public double FindAcceleration(double vi, double vf, double t)
{
return (vf - vi) / t;
}
}
Run that, try it out. Enjoy being able to solve the simplest physics equation I could think of at the time.
But it seems a bit strange, doesn't it? Why would we need to make a new instance 'physics' when no two instances will ever be different. Wouldn't it be nice to just have one set of physics that we can access?
Well we can, by making it static! Let's start by making the method static.
class Physics
{
public static double FindAcceleration(double vi, double vf, double t)
{
return (vf - vi) / t;
}
}
Bam, that easy. We now have a static method that can be invoked without dealing with making new objects. But red lines are showing up when we try to invoke it in our main. This is because the method no longer really belongs to the objects you make, but rather the class, so you can't invoke it is object.StaticMethod(), instead you need to use Class.StaticMethod() as so!
Console.WriteLine();
Physics p = new Physics();
Console.WriteLine("Acceleration = {0} m/s^-2", Physics.FindAcceleration(vi, vf, t));
Console.ReadKey();
Now there is no reason at all to have to make a new type of physics... But we can. It is an empty little object with no use at all, but we can still make one, and that is bad. We know we can make a class unconstructable with the 'abstract' keyword, but that is for when you want things to extend it. Instead, let's use our 'static' keyword again.
static class Physics
{
public static double FindAcceleration(double vi, double vf, double t)
{
return (vf - vi) / t;
}
}
Bam, the class is static, and we can no longer make an instance of it.
Hopefully some of this seems natural to you, as you would have used static methods before by this point. 'Console', for example, is a static class, and when you call it's methods you are calling static methods. You don't need to declare a new instance of Console, you can just use it any place and any time.
The thing to remember is that when you make a static class, all attributes and methods in it
must be static, but when you have a non-static class you can still have static methods/fields, you just have to pretend the class is static while using it.
Now remember how I told you that static was frowned upon? There are several reasons for this.
Firstly, is makes your program more closed to extensions. Let's say you decide that your 'map' class should be static, because your player will only ever see one map, but then later on down the track you change your mind and decide there should be several maps you can visit. Because you used static, you need to go through all this needless bullshit of clearing out your map class! Go play Terraria, and when it says 'Resetting Game Objects' on the loading screen, that is what it is doing. You are waiting because somebody made something static and shouldn't have. Think very carefully, 'is it ever even possible in any way that there might be two different versions of this thing ever?' and if the answer is yes, then
don't make it static.
Secondly, static classes are loaded when your program starts, meaning long waiting times just to get to the options screen. Go play the sims, notice how you need to wait fifteen minutes to load an options screen, but thirty seconds to load a house? It is bullshit, when the only reason I have this game open is because of a misclick, I wanted SimCity! Static classes also remove your power to instantiate them with data from the first tick. If you had a player with a name field and made it static, what do you put in the field before the player enters their name? Leaving it null is very bad practice, much better to wait until we can get the players name before we can even access it. So think 'Is there data that I don't need yet, or do not have yet, contained in this class?' if so, don't make it static.
There are other reasons, but my tea just boiled. Point is they are like duel wielding double ended flaming poison great swords of doom. Given the right problem, they can be an effective diplomatic solution! But do it wrong and you will cut your arm off, and then some people just do not like
violence static and will protest your use of it.
Author
Topic: if self.isCoder(): post() #Programming Thread (Read 944193 times)