Class with a sometimes unused property

Question

From times to times I stumble over the following situation:

I have got a class with a property that's only used if another property has a particular value, for instance:

public enum enum_ConnectionType
{
    Local,
    Server
}

public class Session
{
    private enum_ConnectionType _connectionType;
    private string _serverName; // It only makes sense if _connectionType == enum_ConnectionType.Server

    public Session(enum_ConnectionType connectionType, string serverName)
    {
        _connectionType = connectionType;
        _serverName = serverName;
    }
}

There's something that does not feel right to me. What is your common approach on this kind of situations?

EDIT

I think both Jeff and Leonid answers are valid depending on the situation.

Answer 1

I would do this using an interface and polymorphism to represent this:

public interface ISession
{
    void DoSomething();

    // Add your properties / method definitions
}

public class ServerSession : ISession
{
     private readonly string _serverName;

     public ServerSession(string serverName)
     {
         _serverName = serverName;
     }

     public void DoSomething()
     {
         // Some Code
     }

     // Implement interface contracts
}

public class OtherSession : ISession
{

     public void DoSomething()
     {
         // Some Code
     }

     // Implement interface contracts
}

Then you would use it something like this:

public DoSomethingWithSession(ISession session)
{
     session.DoSomething();
}

foo.DoSomethingWithSession(new ServerSession());

If there is commonality between ISession implementations, you could base class that out, then inherit from that.

Answer 2

There is a different way, supplemented by documentation. One can say that it goes against OOP, one can also say that it keeps things simple and favors composition over inheritance. Here serverName = null is a convention for local connection. This approach condenses the entire state to a single string value.

This is not the only way. Sometimes this is a bad approach, sometimes a good one - depends on how big your architecture is and what your use cases are.

public class Session
{
    private readonly string serverName;

    /// Document me!    
    public Session() : this(null)
    {
    }

    /// Document me!
    public Session(string serverName)
    {
        // Assert serverName is not null or whitespace
        this.serverName = serverName;
    }

    /// Document me!    
    public bool IsLocalConnection
    {
        // Make sure that it is not whitespace
        return this.ServerName == null;
    }

    /// Document me!
    public string ServerName
    {
        get
        {
            return this.serverName;
        }
    }    
}

Answer 3

From a memory perspective I wouldn't worry. A few extra machine words in your class is unlikely to make a difference, and allocators out there tend to pad upwards anyway.

From an OO perspective, you can always make a subclass to add the field.