Question

I am using .NET 3.5 C#. I have a simple connection class with only two methods: OpenConnection() and CloseConnection(). I defined this class as Static so that I don’t have to create an instance while calling methods. I want to know whether:

(1) I should create an interface with method definitions for OpenConnection and CloseConnection and thereby use this Interface with Connection class. There is no reason to use an interface but I was thinking whether the Connection can be made more professional.

(2) Is it fine to declare this class as Static?

Answer 1

There are two entirely different approaches

• Singleton: Single object across the application.

In this case, you will have to take care of the locking mechanism as well.

class Connection
{
    public static Connection Instance() {
        if (_instance == null) {
            lock (typeof(Connection)) {
                if (_instance == null) {
                    _instance = new Connection();
                }
            }
        }
        return _instance;      
    }
    protected Connection() {}
    private static volatile Connection _instance = null;
}

• Implement IDisposable:

Alternatively, you can implement IDisposable in your Connection class, and let it disposed automatically using the using keyword. For instance:

using(Connection c = new Connection(SomeConfiguration)) //Opens the connection.
{
    Something(c);
}// Closes the connection. Dispose is implicitly called in the scope of the using statement.

Or if you want Generic Connection class, then Marc has responded with an excellent database connection class example here.

Regarding point 1; you can use interface; iff:

• You want loose coupling, componentization, and maintainability in your code.

• You want to provide guarantee that the classes shall behave exactly as methods/contracts defined in interface. For instance, in this case, if you extend your class from IDisposable, the interface imposes that not only objects can be disposed without getting compiler errors, but that they should be disposed. So, similar guarantees can be provided in your code by simply adhering to an interface.

• You have a team that is going to working on a large module; and you want to keep code consistent; so you can define an interface and add some restrictions, that would help integrate the it easily. For instance:

You know you have a module that is going to handle alot of connections, different types of connections – some of which may be identified later during the development. But what you know for sure is that all types of connection shall be able to Open and Close; and you also want all of the developers to stick to this rule. So you can come up with an interface like:

interface IMyConnection
{
    Open();//Opens the connection
    Close();//Closes the connection
}

• You expect have certain classes that does a lot of complex work and won’t be finished before the rest of the project; then rest of the project can use the interface and avoid being dependent on that class.

• You plan to deploy your product commercially; and want it to be extendable by 3rd party developers.