Static Means Ether [Notes]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
= Why Static Classes are Pure Evil =

Static Classes are those classes that allow you to access functionality from anywhere in your app, without fuss or bother.

{{{
#!c#
public static DbBackupHelper {
  public static string DoABackupEverySixMonths(){
     string connStringName = ConfigurationManager.AppSettings["OurDefault"];
     ConfigurationManager.ConnectionStrings[connStringName].ConnectionString; 
     ..blah...do something wonderful in the db
  }
}
}}}

The above - because both the class and method definition are marked static means that //anywhere// in your application, you can write something like:

{{{
  public void ItsTimeToBackup(){
   //Presto! All taken care of in one line.
   DbBackupHelper.DoABackupEverySixMonths();
  }
}}} 


== Static Means Ether == 

What the static method just allowed you to do was, like a magician, conjure out of the ether a card/class that allowed you to call a method on it. No messy wiring, no responsability...all handled for you. It just 'happened'.

Isn't that wonderful?


== Magic means Boom ==
Not really. It would have been wonderful if all had gone to plan, but unfortunately, the app was deployed with a misspelt AppSetting, it wasn't able to find the connectionstring, and the whole blew up. There was no way of knowing this, as the method was called only every six months...

== Cutting Ether ==
The problem is the ether -- the fact that you have no idea how to replace the either parts of the operation -- the invoking method, or the invoked service/static method -- with a Mock test replacement.

To unit test something, one can only do so with Mock services that can side step the problems of Integration Tests, that require the whole beast to be up and running. As integration tests are 2 orders of magnitude more expensive to run that unit tests, you can see that mocking is a preferred solution. 

In other words, you need to test things up early. 

How about when bootstrapping?

That's what the [[Design Concepts/SOLID/DI/]] is doing. It's essentially stating that you have to convert the Static classes back into an instance class, bootstrap an IoC with a binding definition of it against a contract, and later either use a ServiceLocator or DI to get the service implementation.

That way , one can replace -- in the bootstrapper -- the service implementation with a mock implementation, at will. 

Neato. I'll have to come back to edit this essay later.