Wrapping up static class with non-static class

Question

I was looking at a project and I found something very curious.

There is a static class that has a set of methods, where each method makes a call to a remote server.

The template looks kind of like this:

public static class DAI

    public static ResponseObject ExecStatement(string db, string sql)
    {
         { ... }
    }

    public static DataSetResponseObject GetDataSet(string db, string sql)
    {
         { ... }
    }

    public static DataTableResponseObject GetDataTable(string db, string sql)
    {
         { ... }
    }
}

But no where in the project makes a call to this class. Instead, it makes a call to an non-static class container.

public class ExecSP : IExecSP
{
    string _db;
    public ExecSP(string db)
    {
        _db = db;
    }

    public ResponseObject OutputAsResponseObject(string sql)
    {
         return DAI.ExecStatement(_db, sql);
    }

    public ResponseObject OutputAsDataSet(string sql)
    {
         return DAI.GetDataSet(_db, sql);
    }

    public ResponseObject OutputAsDataTable(string sql)
    {
         return DAI.GetDataTable(_db, sql);
    }
}

Now, the only two things I see as an advantage is that the nomenclature is more clear when wrapped up in a non-static container, and that there are less parameters to pass around.

But I'm wondering if this is a good idea by design to wrap up static class with non-static? What are some of the other reasons if there are any? Because I assumed that creating a static and making calls to it would be okay. But this project has made it a deliberate point to wrap up all static class; and I'm not sure why.

Answer 1

The most common reason I've done something like this in the past is if the static methods are provided by a third-party library (i.e. I didn't write it), but I don't want to write code that takes a direct dependency on that library. In that case, I'll write my own class and have it take the direct dependency instead.

Assuming I use an interface (or something similar like in your example), then if I decide down the road that I want to use a different library, I can write another class that implements the same interface and swap out the concrete class at runtime (using something like Dependency Injection).

Answer 2

Looks to me like they are trying to make the object injectable in order to make your code easier to test and to modify later.

check this post: Why does one use dependency injection?