Dan Newcome, blog

I'm bringing cyber back

Static method patterns

with 3 comments

When programming with statically-typed OO languages we all have the temptation sooner or later to implement some functionality using static methods. Static methods are “class” methods, which are called on the data types themselves rather than on an instance of a class.

In Microsoft .NET, Static methods are shared among all code that exists within a given application domain (appdomain). Static methods are very convenient for creating code that doesn’t need to deal with any external state, since we don’t have to create an instance of any class in order to call the code.

However, static methods do not participate in inheritance. They exist largely outside of the mechanisms that make object-oriented programming attractive. In light of this fact, I think that most of the time, static methods are an anti-pattern.

Static methods can make code hard to test since it is impossible to replace the static methods with alternative implementations such as mocks or stubs.

There is one workaround that I’ve found which I call the Static Adapter pattern. I have seen some references to this same pattern, and I don’t claim to have invented it, but I don’t see it listed in most classic design patterns books.

A static proxy is just like a classic proxy pattern but the methods on the proxy are static. For example, in a traditional proxy pattern we’d have something like this:

// proxied class
public class Service 
{
    public void DoSomething() {
        // something happens here
    }
}

public class ServiceProxy 
{
    // internally we have an instance of proxied class
    private Service m_service = new Service();

    // proxy the call to DoSomething()
    public void DoSomething() {
        m_service.DoSomething();
    }
}

In order to use the proxy, we do something like the following:

ServiceProxy proxy = new ServiceProxy();
proxy.DoSomething();

Notice that we have to create an instance of the proxy in order to work with it. Now there are two things that I want to extend this code to do. One is to allow me to avoid creating an instance of the proxy, and the other is to allow me to give the proxy a different internal service:

public class ServiceProxy 
{
    // internally we have an instance of proxied class
    public static Service m_service;

    // proxy the call to DoSomething()
    public static void DoSomething() {
        m_service.DoSomething();
    }
}

So now we have a static constructor that allows us to give the proxy its service implementation. The method DoSomething() can also now be called directly as:

ServiceProxy.m_service = new Service();
ServiceProxy.DoSomething();

We still have to specify the internal service for this to work. If we can get away with doing a default instantiation of the service we can do

ServiceProxy.DoSomething();

These static classes cannot implement an interface, but their internal services can. In order to provide a test implementation of some class we can plug in a dummy or test double as the internal service.

That’s enough for this post. I’ll have more to say about static classes and methods later.

Advertisements

Written by newcome

December 14, 2011 at 2:32 am

Posted in Uncategorized

3 Responses

Subscribe to comments with RSS.

  1. As long as they don’t have bizarro static state, I find that you can think of them as chunks of functional programming goodness a lot of the time.

    Harry McIntyre (@mcintyre321)

    December 14, 2011 at 5:29 am

  2. Hey @harry, yes shared state is the killer. The problem in most of the cases that I see is that static classes throw a wrench in the OO works by not supporting inheritance/interfaces. If you are developing in a functional style you can make everything static since there are no side effects.

    newcome

    December 14, 2011 at 9:37 am

  3. Great Explanation. Another great article i recommend is this

    Dharmendra Patel

    April 7, 2012 at 4:11 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: