# Handle static objects using custom adapter

I have read some articles discussing about why static is bad, some of them refering static as not-testable, non-mockable, has state (non-stateless) and everything else.

However I have encountered some cases where I am forced to use static implementation, such as:

• During using HttpContext.Current in Asp.Net, as well as Session
• The HttpContext and Session sometimes contains configurations, which is needed to do some validations
• Accessing some static objects in framework or third-party component
• Maybe there are other situation where I don't yet encountered

Up until now I have handle those static methods using custom adapters (correct me if I misuse the term adapter here, or maybe it is better for provider), such as:

public class ConfigurationAdapter : IConfigurationAdapter
{
{
get
{
return HttpContext.Current.User.Identity.Name;
}
}
}


Then the consumer will use the adapter like:

public class ConfigurationConsumer : IConfigurationConsumer
{
{
}

public void DoSomething()
{
}
}


I believe that this way I can get the benefits:

• The adapter can be replaced by other implementation
• The adapter can be mocked
• The consumer does not directly dependent on HttpContext

However due to inexperienced in design, I am still wondering about:

• Does this kind of implementation can really decouple the consumer with the static object?
• Will it provide any problem in the future?
• Is there any better design or pattern than this?

In this case I want to make sure that my application is testable, maintainable dan extendable. I believe performance is not effecting too much here, so it can be ignored.

Any kind of thoughts will be appreciated

I see no problem in such wrappers except they are kinda cumbersome to write. They provide a good way to decouple your code not only from static objects, but from the all the objects you cannot mock too (for example, sealed classes from 3rd party libraries). I use that kind of adapters myself and have little problem with them. It is important to have these classes as simple as possible (so that you don't need to test them) and only expose properties and methods you realy need.

Update: ctrucza suggests using a service locator in his answer. While it's a good solution when your class has many dependencies which leads to many constructor parameters, it makes unit-testing your class a little harder.

If you add some new dependency into your class and resolve it with some generic service locator's method then your code (including unit tests and production code) will compile just fine. You only realize that something is wrong when your working unit-tests will suddenly fail with null reference exception, or some other resolution exception your service locator provides. The constructor injection, on the other hand, gives you a clear knowledge of what dependencies a class using and if you miss some constructor parameter in your tests, the compiler will tell you.

One more thing. If you have a dozen dependencies in your class, may be the design of the class is wrong and refactoring is needed. I think that's really good indicator, which will be hidden if you are using a service locator pattern.

• Thank you for sharing your experience. Looks like it is the good way to do it anyway. – Fendy Apr 18 '13 at 12:36

The only problem with this otherwise nice and simple approach is when you have many classes which need the adapters: you will have to pass the IConfigurationAdapter to each of them.

If this starts to be a problem I usually try to move towards a ServiceLocator:

public class Configuration
{
public static IConfigurationAdapter CurrentConfiguration { get; set; }
}


and use it like this:

public class ConfigurationConsumer
{
public ConfigurationConsumer()
{
}

public void DoSomething()
{
}
}


or like this:

public class ConfigurationConsumer
{
public void DoSomething()
{

• Not really, Class C should be created with CurrentConfig injected into it. Class C should then be injected into Class B, which is in turn injected into Class A. Therefore, A and B do not know about CurrentConfig. My main objection was the use of statics in a object oriented environment. They take way everything that is good about objects. – Jeff Vanzella Apr 18 '13 at 23:02